Author Topic: Rigol 1054z and 1074z timing problems at 500ms timescale and 24M memory depth  (Read 1524 times)

0 Members and 1 Guest are viewing this topic.

Offline Sredni

  • Regular Contributor
  • *
  • Posts: 222
  • Country: aq
Is this a known bug?

https://electronics.stackexchange.com/questions/517690/rigol-ds1074-oscilloscope-shows-very-wrong-timing

Basically, acquisition at 500ms timescale with memory depth set to 24M gives timing results consistently 4% off.

I wanted to post it in the rigol megathread, but I can't find it. EDIT: I finally found the Rigol megathread and posted there as well to alert all posters there of the issue.
« Last Edit: August 27, 2020, 10:09:33 pm by Sredni »
All instruments lie. Usually on the bench.
 

Online Howardlong

  • Super Contributor
  • ***
  • Posts: 4940
  • Country: gb
Is this a known bug?

https://electronics.stackexchange.com/questions/517690/rigol-ds1074-oscilloscope-shows-very-wrong-timing

Basically, acquisition at 500ms timescale with memory depth set to 24M gives timing results consistently 4% off.

I wanted to post it in the rigol megatrhead, but I can't find it.

I don't know if it's a known bug, but it seems to be that capturing at 4.00MSa/s ain't right (500ms/div, single channel, 24MSa). On mine, a 1Hz square wave calculates as 961mHz, and you can see it's not right. Recaptured at 200ms/div and 1s/div looks fine.

[attachimg=1]

[attachimg=2]

[attachimg=3]
 

Online tautech

  • Super Contributor
  • ***
  • Posts: 19182
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
I don't know if it's a known bug, but it seems to be that capturing at 4.00MSa/s ain't right (500ms/div, single channel, 24MSa).
Welcome to the world of DSO memory/sampling rate management.

Looks as it should do to me......apart from the counter.
Avid Rabid Hobbyist
 

Offline Sredni

  • Regular Contributor
  • *
  • Posts: 222
  • Country: aq
After posting here, I did some other test using the 1kHz test signal and the 4% error is there and is reproducible. Just acquire it with 24M with a 500ms timebase and the period will be 1.040 ms instead of 1.000 ms.
And if the acquisition is done with a 5s timebase, the period will come out as 800us, a 20% error.

(images at the updated link above)
All instruments lie. Usually on the bench.
 

Online Howardlong

  • Super Contributor
  • ***
  • Posts: 4940
  • Country: gb
I don't know if it's a known bug, but it seems to be that capturing at 4.00MSa/s ain't right (500ms/div, single channel, 24MSa).
Welcome to the world of DSO memory/sampling rate management.

Looks as it should do to me......apart from the counter.

It's not aligned with the graticule.
 

Online tautech

  • Super Contributor
  • ***
  • Posts: 19182
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
I don't know if it's a known bug, but it seems to be that capturing at 4.00MSa/s ain't right (500ms/div, single channel, 24MSa).
Welcome to the world of DSO memory/sampling rate management.

Looks as it should do to me......apart from the counter.

It's not aligned with the graticule.
Oh that bit, yes maybe a bug or the unit is in need of Self Cal.  :-//
Avid Rabid Hobbyist
 

Offline PeDre

  • Regular Contributor
  • *
  • Posts: 156
  • Country: at
    • Private Website
When I read the data from the memory, there is also a 4% difference. So it is not a display error in the screen data.
 

Offline Sredni

  • Regular Contributor
  • *
  • Posts: 222
  • Country: aq
Oh, for being a bug, it is a bug.
I wonder if it has been already fixed or if it is present even in the latest firmware. My firmware version is kinda old: 00.04.04.01.01 and I did not upgrade anymore since I had read about an error in one of the subsequent versions of the firmware.

The 800 us period of the 1kHz test signal is... unsettling.
All instruments lie. Usually on the bench.
 

Offline PeDre

  • Regular Contributor
  • *
  • Posts: 156
  • Country: at
    • Private Website
I have tested with the latest firmware v04.04.SP3
 
The following users thanked this post: Sredni

Online Fungus

  • Super Contributor
  • ***
  • Posts: 11116
  • Country: 00
Oh, for being a bug, it is a bug.
I wonder if it has been already fixed or if it is present even in the latest firmware. My firmware version is kinda old: 00.04.04.01.01 and I did not upgrade anymore since I had read about an error in one of the subsequent versions of the firmware.

FWIW it happens on mine, too.

The 800 us period of the 1kHz test signal is... unsettling.

Me? I wouldn't be too unsettled by something that took five years for anybody to even notice it.
 

Offline Sredni

  • Regular Contributor
  • *
  • Posts: 222
  • Country: aq

The 800 us period of the 1kHz test signal is... unsettling.

Me? I wouldn't be too unsettled by something that took five years for anybody to even notice it.

Well, the point in my opinion is that this is a behaviour nobody would expect even in an entry level scope. It has gone unnoticed because people did not question the timing of well behaved signals at certain sample rates and memory depths only.
This is an embarassing bug because it seems to be caused by flawed implementation of a mathematical routine.

If it does that at 24M of memory and 4 MS/s when the time base is a 0.5 and 5 seconds, maybe it will happen with other combinations of memory depth, sampling rate and timebase. A 20% error in timing when you have no idea when it could happen, makes this scope more similar to a reverse slot machine. If you get the wrong combination, you hit the jackasspot.

Luckily nobody would use an entry level hobbyist scope for anything serious but I wonder if this bug happens in the next level line up, such as the DS2000 series.
If the firmware are based on the same mathematical algorithms, it might as well be the case...

« Last Edit: August 23, 2020, 11:47:05 pm by Sredni »
All instruments lie. Usually on the bench.
 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 3251
  • Country: cn
  • Born with DLL21 in hand

The 800 us period of the 1kHz test signal is... unsettling.

Me? I wouldn't be too unsettled by something that took five years for anybody to even notice it.

Well, the point in my opinion is that this is a behaviour nobody would expect even in an entry level scope. It has gone unnoticed because people did not question the timing of well behaved signals at certain sample rates and memory depths only.
This is an embarassing bug because it seems to be caused by flawed implementation of a mathematical routine.

If it does that at 24M of memory and 4 MS/s when the time base is a 0.5 and 5 seconds, maybe it will happen with other combinations of memory depth, sampling rate and timebase. A 20% error in timing when you have no idea when it could happen, makes this scope more similar to a reverse slot machine. If you get the wrong combination, you hit the jackasspot.

Luckily nobody would use an entry level hobbyist scope for anything serious but I wonder if this bug happens in the next level line up, such as the DS2000 series.
If the firmware are based on the same mathematical algorithms, it might as well be the case...

It is intersting speculation if think...

Someone have this in place where all instruments need have calibration certification.
Now it they send also this to cal lab who check instruments and write certificates. Who believe this Rigol get pass in tests and after then it have certificate and cert. sticker somewhere in front panel etc.  All happy use it and measured results are now made with nist traceable cal. instrument.
Who have enough loose money for test. Send it with company other instruments to get new cal cert and without any notice about possible err.
My forecast is, in return shipment there is one Rigol what have certificate.

How about Rigol own factory calibration where they proof that it meets its specifications and even list about test instruments used for check/factory calibration and nice story how they are traceable to standards. This case show that whole process is just bullshit. They have not made any kind of full calibration check as it need do. If they have done it, it is not now here. How factory own calibration check can not detect this error what is not small. 4% abs acc. in vertical... blah...not big alarm if happen.
 
But this error is in horizontal time axis! This is controlled by scope TCXO or what ever timebase what have some specifications in ppm units. This make big difference.

Perhaps if take this 24M data out and analyze it carefully and calculate some things with some experimental tests may tell is it partially math problem in scaling to display or is it also in measurement small intermediate buffer or is it in whole true capture memory.
In capture memory there is not floating "math" if they have done it right. There must be only decimation.
I do not know what is real ADC samplerate in Rigol ADC in every cases.

Is it possible to check if this failure also exist with same other settings but also then with 1, 2 and 3 or 4 channels in use simultaneously. Yes it drops true ADC samplerate and of course divide also memory.

If ONE Ch is in use and very slow time scale... like example 500ms/div  do they take all 4 ADC interleaved samples and decimate it or do they take just only one ADC and decimate it to get decimated 4MSa/s.

Speculation. If they use full 4 ADC interleaved stream when one Channel open. it is 1GSa/s. For 4MSa/s it need decimate by 250.  (drop out 249 and keep one and forward it to capture memory)

If they use only one ADC (no interleaving) there is 250Msa/s true ADC speed (well enough also for this timescale). For 4MSa/s they need decimate by  62.5 what is impossible except is do not use constant decimation but 62 and 63 sequentially what is ... not so nice. 
If it is just pure decimation error it can perhaps detect when look saved acquisition memory  with computer and using some external test signals.

But, how factory have tested it so that they can write proof  that it meet its specifications. Of course it need check with every single time scale. This is how we have done it in tens of years when there was only analog scopes and still it need do so today and for every timescale just for detect some  programming errors in production. After it is checked then do not need every time check every time scale. Program do not drift. In analog scopes even this need check in every calibration procedure, as can see example in Tektronix old full service and calibration manuals.

Is it possible that this have happen accidentally in some FW update or have this error been always after product start what is then even really more severe because then it tell they have never true checked it for proof specifications.
They think, as many chinese companies, that customers are good for do beta tests or even more early tests.
One bad is that some cases in some poor company perhaps same peoples do final tests before launching phase who are designing HW and who are programmers. This is real class A mistake.

There need be separate test team who are far away from designers in test phase and more error they find more money they get, minor errors bit less and finding fatal class major error give pocket full of bank notes. This works. Why chinese and indian etc some companies jumps over this like lazy fox.


Some say that this is not serious because it is only hobby scope. Really  |O
Who think hobbyists are some group what can eat what ever shit and crap fnirsijokes.
This instrument have specifications. Who can think specifications can be like joke stories or other trumpths.
This scope you can find in many places in real work and not only as hobbyist hobby corner decoration.

No, this is real and serious error what responsible company need urgently repair and also better if set public Notice about this error so that users can avoid this error trap. I remember well HP and Tektronix Notification and Errata letters before arpanet and now internet.

If practice and theory is not equal it tells that used application of theory is wrong or the theory itself is wrong.
-
Harmony OS
 

Offline PeDre

  • Regular Contributor
  • *
  • Posts: 156
  • Country: at
    • Private Website
Luckily nobody would use an entry level hobbyist scope for anything serious but I wonder if this bug happens in the next level line up, such as the DS2000 series.
If the firmware are based on the same mathematical algorithms, it might as well be the case...

With the Rigol MSO2302A with the latest firmware 03.06, I did not find any error. But I only tested with the 500 ms/DIV.
 
The following users thanked this post: Sredni

Online Fungus

  • Super Contributor
  • ***
  • Posts: 11116
  • Country: 00
No, this is real and serious error what responsible company need urgently repair

I agree that this should be fixed. I don't agree that the sky is falling.

(and you'd know why if you actually tried to reproduce it instead of just spouting...)
 
The following users thanked this post: Gandalf_Sr

Offline Adrian_Arg.

  • Frequent Contributor
  • **
  • Posts: 275
  • Country: ar
I agree, Rigol should solve the failure as soon as possible, I don't think it is that difficult.
 

Offline SERJSOCHI

  • Contributor
  • Posts: 11
  • Country: ru
Same problem.
 

Offline Adrian_Arg.

  • Frequent Contributor
  • **
  • Posts: 275
  • Country: ar
I sent an email to rigol with an explanation of the problem and a screenshot. for now acknowledgment of receipt.
       To: Info-Intl
       Subject: BUG rigol dsz1000z
       Posted on: 8/25/2020 12:06 PM

was read on 8/25/2020 10:16 PM.
 
The following users thanked this post: RoGeorge, SERJSOCHI

Offline Sredni

  • Regular Contributor
  • *
  • Posts: 222
  • Country: aq
LOL, the OP on EESE (OMG! WTF am I doing with all this acronyms?) has received a reply from Rigol, saying to upgrade to the version of firmware he already has, and that is affected by the bug.
(This information is in the comments, and the question has been closed as off-topic - in fact it's not a question about how to find the resistance for a LED... >:D )

Perhaps somebody should write a bug report in Chinese?
« Last Edit: August 26, 2020, 09:09:54 pm by Sredni »
All instruments lie. Usually on the bench.
 

Online Howardlong

  • Super Contributor
  • ***
  • Posts: 4940
  • Country: gb
LOL, the OP on EESE (OMG! WTF am I doing with all this acronyms?) has received a reply from Rigol, saying to upgrade to the version of firmware he already has, and that is affected by the bug.
(This information is in the comments, and the question has been closed as off-topic - in fact it's not a question about how to find the resistance for a LED... >:D )

Perhaps somebody should write a bug report in Chinese?

The value of the websites like that is so degraded by activity such as marking things as "off topic" to close them.

The other useless trick they use, presumably to fraudulently improve their click rate, is to mark completely unsolved questions as solved. Toms Hardware is probably the worst for falsely claiming unsolved questions as solved.

Of course, there's no reasonable way open to contest these arbitrary and disingenuous decisions.
« Last Edit: August 26, 2020, 09:30:37 pm by Howardlong »
 

Offline Elmue

  • Newbie
  • Posts: 1
  • Country: de
Hello

I'am the "OP" how published the bug at StackExchange.

My thread has been reopened. So I could post an answer now:

https://electronics.stackexchange.com/a/518731/101597
 
The following users thanked this post: Kean

Offline BlackDogWhite

  • Newbie
  • Posts: 1
  • Country: us
Just accept that I'm an idiot. 

How do I select some different Sa rate?  The menu item always seems disabled.
 

Online Kean

  • Supporter
  • ****
  • Posts: 1074
  • Country: au
  • Embedded systems & IT consultant
    • Kean Electronics
Just accept that I'm an idiot. 

How do I select some different Sa rate?  The menu item always seems disabled.

You need to change the memory depth which then changes sample rate based on timebase.  Or at least that is what I did.
You also must be in run mode to change it, and only have channel 1 enable.

I tested it on my MSO1104Z and got the same results.  I added a reply with my findings on Stack Exchange.
 

Offline Adrian_Arg.

  • Frequent Contributor
  • **
  • Posts: 275
  • Country: ar
We have to flood Rigol with emails with complaints, to see if we can get them to fix the failure.

in spanish
nosotros tenemos que inundar de mails con reclamos a Rigol, para ver si  conseguimos que arreglen el fallo.
 

Online Fungus

  • Super Contributor
  • ***
  • Posts: 11116
  • Country: 00
Just accept that I'm an idiot. 

How do I select some different Sa rate?  The menu item always seems disabled.

You can only change it when the 'scope is running, not when it's paused.
 

Offline Adrian_Arg.

  • Frequent Contributor
  • **
  • Posts: 275
  • Country: ar
It would be good to know how many users of the rigol ds1000z have made the claim to rigol ::)


Seria bueno saber cuantos usuarios del rigol ds1000z han hecho el reclamo a rigol ::)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf