Author Topic: Rigol DS1000Z series buglist continued (latest: 00.04.04.04.03, 2019-05-30)  (Read 110258 times)

0 Members and 1 Guest are viewing this topic.

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #100 on: May 01, 2017, 10:12:22 pm »
That would be nice. The offset does aggravate the OCD. :-DD
TEA is the way. | TEA Time channel
 
The following users thanked this post: garnix

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7547
  • Country: 00
  • +++ ATH1
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #101 on: May 02, 2017, 07:19:20 am »
I don't think I will try an "LFCal" any time soon...

Definitely not me either.  :scared:

Dunno, I have a feeling that someone that will be brave enough to modify their cal file to certain extreme values at each entries, load it and compare the measurement results with previous loaded cal that was altered to "another" extreme values, just for the sake to decode that file alone.  >:D

Probably those people who contribute at this thread ->  Rigol DS10xxZ firmware re-write

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16560
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #102 on: May 02, 2017, 08:03:34 am »
I can't figure out, however, what this would be used for. Why would one want to store and recall a calibration

Beats me.  :-//

I could understand it if calibration was only done by an expensive calibration service center and comes with a certificate. On a DS1054Z you just press a button to make a new one.

I guess those to buttons are only meant for debugging or service purposes anyway.

Yep. I'm guessing somebody at Rigol added it so they can compare calibration results with different firmware versions.

Has anybody looked at the file? Is it binary/ASCII? How big is it? If it's binary, have we got a hex dump?

More important: Is it calibration data or is it a log file of the last calibration process? (which would make a lot more sense)

« Last Edit: May 02, 2017, 08:44:17 am by Fungus »
 

Offline video

  • Newbie
  • Posts: 7
  • Country: fr
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #103 on: May 02, 2017, 08:44:13 am »
In this file, there're 4 parts with a (chinese/japanese ?)  title: i don't read or speak this very complex language, i don't know exactly what it is; i tried a google and online dictionnary search, but not easy; if somebody can translate this header, it will be interesting for understand, even partially, the content of the file, but i don't know asian person to help us  :(
this is a part of the CalData.txt:

------------------????????---------------------
{
 {
  0,0x5b,1,1,
  0,0x4f,1,1,
 },etc..
------------------?????????---------------------
------------100M-----------
{
{//CH1
500       ,ATT_X1  ,G_X2    ,1  ,13 ,4154  ,
1000      ,ATT_X1  ,G_X2    ,1  ,13 ,2077  ,
2000      ,ATT_X1  ,G_X2    ,1  ,13 ,1038  ,
5000      ,ATT_X1  ,G_X2    ,1  ,10 ,1038  ,
10000     ,ATT_X1  ,G_X2    ,1  ,7  ,1038  ,
20000     ,ATT_X1  ,G_X2    ,1  ,5  ,1038  ,
50000     ,ATT_X1  ,G_X2    ,1  ,2  ,1038  ,
100000    ,ATT_X1  ,G_X0625 ,1  ,3  ,1362  ,
200000    ,ATT_X1  ,G_X0625 ,1  ,1  ,1362  ,
500000    ,ATT_X50 ,G_X2    ,1  ,7  ,1060  ,
1000000   ,ATT_X50 ,G_X2    ,1  ,5  ,1060  ,
2000000   ,ATT_X50 ,G_X2    ,1  ,3  ,1060  ,
5000000   ,ATT_X50 ,G_X0625 ,1  ,3  ,1390  ,
10000000  ,ATT_X50 ,G_X0625 ,1  ,1  ,1390  ,
},etc..
-------------????-------------
{
{
101.423302,101.811897,102.006195,ATT_X1  ,G_X2    ,10 ,1024  ,
332.540192,333.123077,334.094574,ATT_X1  ,G_X0625 ,10 ,1024  ,
},etc..
-------------??????-------------
------------100M-----------
{
{,32918,32885,32819,32821,32826,32833,32868,35007,37103,32841,32862,32910,35116,37377},
{,32937,32904,32839,32839,32841,32852,32859,34938,37030,32851,32866,32899,35018,37213},
{,32901,32869,32803,32805,32807,32812,32818,34776,36774,32815,32831,32857,34866,36993},
{,32930,32897,32831,32836,32842,32850,32898,34939,37130,32853,32875,32923,35078,37335},
},etc..
 

Offline video

  • Newbie
  • Posts: 7
  • Country: fr
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #104 on: May 02, 2017, 08:47:49 am »
 :-[ Sorry, but the chinese/japanese characters are changed by smiley in my post, i didn't check that by preview, so lock in your own file to see its
 

Online tautech

  • Super Contributor
  • ***
  • Posts: 28134
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #105 on: May 02, 2017, 09:05:15 am »
:-[ Sorry, but the chinese/japanese characters are changed by smiley in my post, i didn't check that by preview, so lock in your own file to see its
Drop it into some document, Word, txt... and attach it in a post of try dropping it within the brackets for Insert Table (below Font Face) when you make a post. Like this:

FILE CONTENTS

Quote this post and you can see the syntax used.
Avid Rabid Hobbyist
Siglent Youtube channel: https://www.youtube.com/@SiglentVideo/videos
 

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7547
  • Country: 00
  • +++ ATH1
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #106 on: May 02, 2017, 10:27:50 am »
Has anybody looked at the file? Is it binary/ASCII? How big is it? If it's binary, have we got a hex dump?

Here you go, attached below zipped, its a text file with some headers presumably Chinese characters.  :-//

Please be reminded, also to others, this is from DS1104Z-S (with func gen), "NOT" a hacked DS1054Z.

Online ebastler

  • Super Contributor
  • ***
  • Posts: 6202
  • Country: de
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #107 on: May 02, 2017, 10:34:58 am »
Attached is the screencopy of "LFCal".

Do you also get the error message when a USB stick with a previously saved calibration file is present?
 

Offline zbyr

  • Contributor
  • Posts: 23
  • Country: pl
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #108 on: May 02, 2017, 10:55:35 am »
I tried google translate with these chinese characters, and it seems ok.

Attached file with translated headers.
 

Offline video

  • Newbie
  • Posts: 7
  • Country: fr
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #109 on: May 02, 2017, 11:54:27 am »
Thanks for the  chinese-english translation zbyr, and my idea about "LFCal" for load file calibration wasn't good, ebastler was maybe more near to the truth.
I compared the 2 CalData files from the DS1104Z-S and the DS1054Z, the structure are similar, the 2 channels generator is probablely not concerned by this caldata file. PeDre, i can't find the [SCPI command for the "LFCal" function ":CALibrate:LFSTARt", and for the "OUTPUT" function ":CALibrate:OUTPut?"] in the Rigol programming guide: did you find it in an official doc ?
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #110 on: May 14, 2017, 02:48:35 pm »
In case somebody thought that most bugs have been solved, I have an unpleasant surprise:

The command :FUNCtion:WREPlay:FMAX? returns the value that belongs to :FUNCtion:WREPlay:FEND
instead of the number of recorded frames.

Example: 5 frames have been recorded. :FUNCtion:WREPlay:FEND is set to 5.
When using the command :FUNCtion:WREPlay:OPERate PLAY, it plays the 5 frames as expected.
Now use the command :FUNCtion:WREPlay:FEND 3 to playback frames 1 to 3.
When using the command :FUNCtion:WREPlay:OPERate PLAY, it plays the 3 frames as expected.
Now, when requesting the maximum number of frames that can be set to playback using the command :FUNCtion:WREPlay:FMAX?
it returns 3 instead of 5.

 :--

Together with all other (resolved) bugs, it explains why their pc software is so shitty.
It's impossible to write good remote control software when the firmware doesn't work as documented.
« Last Edit: May 14, 2017, 02:51:23 pm by Karel »
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16560
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #111 on: May 14, 2017, 04:02:19 pm »
In case somebody thought that most bugs have been solved, I have an unpleasant surprise:

The command :FUNCtion:WREPlay:FMAX? returns the value that belongs to :FUNCtion:WREPlay:FEND
instead of the number of recorded frames.

Example: 5 frames have been recorded. :FUNCtion:WREPlay:FEND is set to 5.
When using the command :FUNCtion:WREPlay:OPERate PLAY, it plays the 5 frames as expected.
Now use the command :FUNCtion:WREPlay:FEND 3 to playback frames 1 to 3.
When using the command :FUNCtion:WREPlay:OPERate PLAY, it plays the 3 frames as expected.
Now, when requesting the maximum number of frames that can be set to playback using the command :FUNCtion:WREPlay:FMAX?
it returns 3 instead of 5.

That's correct behavior.

Read the manual:



 

Offline metrologist

  • Super Contributor
  • ***
  • Posts: 2199
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #112 on: May 14, 2017, 04:14:24 pm »
maybe because that is the way they've written it, but I would expect the FEND? keyword. that stuff happens to the best anyway...
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #113 on: May 14, 2017, 04:34:28 pm »
I have read the manual and it's not correct behaviour. Thank you very much.

Instead of showing me a screenshot of a part of the manual that I have already read for three times, you could maybe offer
some arguments or reasoning why you think it is correct.


The maximum number of frames recorded is 5.

The maximum number of frames to be played back is set to 3.

The query to maximum number of frames that can be played back should be the number of recorded frames: 5.

The query to maximum number frames set to playback is 3.

Quote
:FUNCtion:WREPlay:FMAX?
Description Query the maximum number of frames can be played, namely the maximum number of frames recorded.

When you set the end frame for playback, you don't change the number of recorded frames.
 

Offline pascal_sweden

  • Super Contributor
  • ***
  • Posts: 1539
  • Country: no
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #114 on: May 14, 2017, 05:04:26 pm »
Who is actually communicating all these bugs to Rigol? Or is there a Rigol application engineer on this forum?
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #115 on: May 14, 2017, 05:20:55 pm »
Who is actually communicating all these bugs to Rigol? Or is there a Rigol application engineer on this forum?

A couple of forum members have reported most of the bugs.

To my knowledge, no Rigol representative visits this forum.
If they do, they do it quietly.
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16560
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #116 on: May 14, 2017, 05:47:09 pm »
I have read the manual and it's not correct behaviour. Thank you very much.

Instead of showing me a screenshot of a part of the manual that I have already read for three times, you could maybe offer
some arguments or reasoning why you think it is correct.


The maximum number of frames recorded is 5.

The maximum number of frames to be played back is set to 3.

The query to maximum number of frames that can be played back should be the number of recorded frames: 5.

The query to maximum number frames set to playback is 3.

Quote
:FUNCtion:WREPlay:FMAX?
Description Query the maximum number of frames can be played, namely the maximum number of frames recorded.

When you set the end frame for playback, you don't change the number of recorded frames.

My "argument" is that on the very next line of the manual, under the one you're throwing around, it says this:

Code: [Select]
Use the :FUNCtion:WRECord:FEND command to set the maximum number of frames
recorded.

So yes, it does change the number of recorded frames.

You may not like the function, but it's not a bug.  :popcorn:

PS: You can play back a subset of frames using the ":FUNCtion:WREPlay:FCURrent" function, or just start playing and monitor the current position.
« Last Edit: May 14, 2017, 05:51:04 pm by Fungus »
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #117 on: May 14, 2017, 06:16:17 pm »
I'm not talking about :FUNCtion:WRECord:FEND.

I'm talking about :FUNCtion:WREPlay:FMAX

Changing the setting for :FUNCtion:WREPlay:FMAX has nothing todo with :FUNCtion:WRECord:FEND.

Recording and playback are two completely different things. Once you have recorded some frames (5 in the xample),
you can playback them, either all five or just one or only frame 2 to 4. This does not affect the number of frames stored in memory.

After playback has finished, you can playback again the same frames or set other values for the number of frames to playback.
Again, as long as you don't record again, the number of recorded frames stays the same.

What's so difficult  to understand about this?
 

Offline kcbrown

  • Frequent Contributor
  • **
  • Posts: 880
  • Country: us
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #118 on: May 14, 2017, 08:42:27 pm »
I'm not talking about :FUNCtion:WRECord:FEND.

I'm talking about :FUNCtion:WREPlay:FMAX

Changing the setting for :FUNCtion:WREPlay:FMAX has nothing todo with :FUNCtion:WRECord:FEND.

The documentation clearly claims otherwise.


Quote
Recording and playback are two completely different things. Once you have recorded some frames (5 in the xample),
you can playback them, either all five or just one or only frame 2 to 4. This does not affect the number of frames stored in memory.

After playback has finished, you can playback again the same frames or set other values for the number of frames to playback.
Again, as long as you don't record again, the number of recorded frames stays the same.

What's so difficult  to understand about this?

If the documentation says that "function A reads value X, and function B sets value X", then how is it a bug when your use of B results in A reporting the value that you handed to B?
« Last Edit: May 14, 2017, 08:44:37 pm by kcbrown »
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #119 on: May 14, 2017, 10:00:16 pm »
I'm not talking about :FUNCtion:WRECord:FEND.

I'm talking about :FUNCtion:WREPlay:FMAX

Changing the setting for :FUNCtion:WREPlay:FMAX has nothing todo with :FUNCtion:WRECord:FEND.

The documentation clearly claims otherwise.

No, it doesn't. Please show me where it does.

Quote
Recording and playback are two completely different things. Once you have recorded some frames (5 in the xample),
you can playback them, either all five or just one or only frame 2 to 4. This does not affect the number of frames stored in memory.

After playback has finished, you can playback again the same frames or set other values for the number of frames to playback.
Again, as long as you don't record again, the number of recorded frames stays the same.

What's so difficult  to understand about this?

If the documentation says that "function A reads value X, and function B sets value X", then how is it a bug when your use of B results in A reporting the value that you handed to B?

It doesn't. The documentation says  that "function A reads value X, and function B sets value Y".

:FUNCtion:WRECord:FEND sets or contains the number of recorded (or to be recorded) frames in memory.

Let's say, we set this value to 5. After that we start a recording. After the recording has finished, the memory contains 5 frames.

Now we can set the range of frames we want to playback by setting the start frame and the stop frame.
For that we use the commands :FUNCtion:WREPlay:FSTart and :FUNCtion:WREPlay:FEND.
Setting those commands does not alter the settings for recording.
We can playback as many times we want. We can also change the range of frames that we want to playback.
That doesn't alter the content of the memory as long as we don't start a new recording.
The maximum frame number for playback must be less than, or equal to, the max number of frames in memory.

The command :FUNCtion:WREPlay:FMAX tells us what is the maximum frame number we select for playback.
Obviously, the maximum frame number for playback must be less than, or equal to, the max number of frames in memory:

"Syntax :FUNCtion:WREPlay:FMAX?

Description Query the maximum number of frames can be played, namely the maximum number of frames recorded."

That's clear, the command returns the maximum frame number we set for the range of frames we want to playback.
Ofcourse that number can not be more than the number of frames in memory.

"Explanation Use the :FUNCtion:WRECord:FEND command to set the maximum number of frames recorded."

That's also clear. We have used this command before starting the recording in order to set the number of frames that must be
recorded.

Initially, when using the command :FUNCtion:WREPlay:FMAX? it tells us the correct maximum: the number of frames in memory.

Now let's say you use the command :FUNCtion:WREPlay:FEND to define the end frame for the range of frames to be played back,
and set it to a lower number.
When playing back again, the number of frames being played back are adjusted accordingly.

So far so good. Now use the command :FUNCtion:WREPlay:FMAX? again. Now it shows a lower number!
Somehow magically the number of frames in memory have been lowered! (Which isn't true by the way)

:FUNCtion:WREPlay:FEND != :FUNCtion:WRECord:FEND  !!

 

Offline kcbrown

  • Frequent Contributor
  • **
  • Posts: 880
  • Country: us
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #120 on: May 14, 2017, 11:32:47 pm »
:FUNCtion:WREPlay:FEND != :FUNCtion:WRECord:FEND  !!

Ah.  Yes, you're right, those should be different.   My apologies.  So it appears the internals are confusing the two, which is a bug.




Sent from my iPhone using Tapatalk
 

Offline technogeeky

  • Frequent Contributor
  • **
  • Posts: 555
  • Country: us
  • Older New "New Player" Player Playa'
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #121 on: May 15, 2017, 02:50:59 am »
In case Rigol does ever visit: Rigol would, at this point, have nothing to lose and everything to gain by releasing/open sourcing the firmware.





  • It would be easy for them to determine people who brick their scopes from firmware changes.
  • Clearly there aren't companies even younger than Rigol trying to copy them.
  • It would allow Rigol to do absolutely no product development and still increase their pressure on the competition
. For example, if you compare the new Keysight scope which is a few hundred dollars more to the 1054z, it's a difficult decision perhaps. But if you compare the Keysight with the Rigol 1054z with open source and community improved firmware, then it's no contest. All of the features of the Keysight could easily be added to the 1054z.[/li][/list].
  • Rigol could even re-use the improvements in future scopes; allow customers to adapt features they like from competitor's scopes (like Rhode and Schwartz's amazing serial decode UI) and re-integrate these features into their scopes while being liability free...

I don't really see the downside. The Rigol 1054z is already probably the best selling oscilloscope of all time. The software feature keying mechanism is already hacked.

Can anyone else here come up with business arguments that would make this move a clear win? Is there something I'm missing, where they will be throwing away something that Rigol considers critical?

Cheers,
-tg
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16560
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #122 on: May 15, 2017, 03:56:14 am »
:FUNCtion:WREPlay:FEND != :FUNCtion:WRECord:FEND  !!
Ah.  Yes, you're right, those should be different.   My apologies.  So it appears the internals are confusing the two, which is a bug.

Oh, duh! Yes.  :palm:

 

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #123 on: May 15, 2017, 04:30:17 am »
I had to read through that a few times, as well, since the commands are very similar looking. Perhaps the bug arose from a similar confusion during coding of the functionality. Nice bug find, Karel.

Regarding Rigol doing something because it would seem to make sense to, I have one word for it: "pluses". :horse:

Seriously, though, it would be nice to be able to fix things ourselves. But, alas, we're the minority. Hence, I'd be skeptical of it happening, but very pleased if it did.
TEA is the way. | TEA Time channel
 

Offline boggis the cat

  • Regular Contributor
  • *
  • Posts: 218
  • Country: nz
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #124 on: May 15, 2017, 05:41:40 am »
In case Rigol does ever visit: Rigol would, at this point, have nothing to lose and everything to gain by releasing/open sourcing the firmware.

...

Can anyone else here come up with business arguments that would make this move a clear win? Is there something I'm missing, where they will be throwing away something that Rigol considers critical?

Cheers,
-tg
I am surprised that none of the low-cost manufacturers have considered this.  After all, if your firmware is already being hacked, why not harness that work?

One argument against this would be that someone could grab that code-base and install it is their own hardware, precluding any significant software development.  This could end up with the first-mover manufacturer having both their hardware design and software copied rapidly by competitors.

Although, if the DS/MSO1xxxZ series is now due for replacement (due to Siglent's recent release -- likely to be followed up by a four channel option at minimum), then it may well be worth the experiment.  Hantek or someone lower down the quality chain might take your code, but then they're stuck on the now obsolete hardware platform so are still lagging you.

(Another argument may be that more could be squeezed from older products, thus disrupting the 'upgrade cycle'.  I don't know how big a factor this is.)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf