Thanks skander36
I didn't think to try that. The command needed is
:SYST:OPT:UNINSTALL
SCPI is not case sensitive, as bitseeker pointed out. By convention in documentation the lower case parts are supposed to be optional.
So unless this is a bug and :SYST:OPT:UNINST used to work on previous FW releases the manual is wrong and should say
:SYSTem:OPTion:UNINSTALL
Which is pretty unusual since the parts of SCPI commands are not more than 5 characters in general
Lets say that Rigol is not a prime example of scpi implementation...
Lets say that Rigol is not a prime example of scpi implementation...
You'll probably find it works perfectly if you send an SCPI newline instead of copying/pasting with a Windows newline.
I don't know if the Rigol accepts a carriage return + linefeed
:WAV:MODE:NORM
:syst:err?
-113,"Undefined header; keyword cannot be found"
:WAV:MODE NORM
:syst:err?
0,"No error"
:WAV:MODE STAR 1201
:syst:err?
-220,"Parameter error"
:syst:err?
0,"No error"
So far all good, as expected.:WAV:STAR 1201
:WAV:STAR 120
:syst:err?
That's it, SCPI hangs until the next power on.
NEW BUG (Software 00.04.04.SP3, Board 0.1.1): When a bad SCPI command is followed by another command, then query the error queue using ":SYST:ERR?", the SCPI will become unresponsive until the next power cycle.
It would be more interesting to know wether they fixed the design problems with the PLL circuitry.
Why, what problem is it causing?
It would be more interesting to know wether they fixed the design problems with the PLL circuitry.
Why, what problem is it causing?
I was planning on a SDS2000X at 3.5x the price of the DS1054Z, but programming was a total showstopper.
It would be more interesting to know wether they fixed the design problems with the PLL circuitry.
Why, what problem is it causing?A few but Fungus doesn't really want to answer this fully.
Members MarkL and Bud are those that narrowed it down to design problems with the PLL and then Dave did a vid on it.
https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/
Then Bud started looking hard at his own DS2000A, which he documented in full:
https://www.eevblog.com/forum/projects/project-yaigol-fixing-rigol-scope-design-problems/
So yes, if there is a new revision MB it will be interesting to see if these things have been addressed,
It would be more interesting to know wether they fixed the design problems with the PLL circuitry.Why, what problem is it causing?A few but Fungus doesn't really want to answer this fully.
Members MarkL and Bud are those that narrowed it down to design problems with the PLL and then Dave did a vid on it.
It would be more interesting to know wether they fixed the design problems with the PLL circuitry.Why, what problem is it causing?A few but Fungus doesn't really want to answer this fully.
Members MarkL and Bud are those that narrowed it down to design problems with the PLL and then Dave did a vid on it.
And... then what happened?
It looks like a few people don't want to tell the whole story, they prefer to keep on hating.
For anybody wondering:
3) Rigol issued a firmware update.
4) Now it all works perfectly.
Dave even did another video to confirm it but I guess you lost the URL to that one, right?
If anybody knows where I can find the steps to reproduce the PLL/jitter problems, please tell me, and I'll give it another try.
I just tested my DS1054Z for jitter, and it's rock solid, no jitter at all.
In the pic is more than 10 minutes of run with infinite persistence for either sinus and square waveform.
I was planning on a SDS2000X at 3.5x the price of the DS1054Z, but programming was a total showstopper.
Can you elaborate on that?
You won't reproduce it unless you roll back to very early firmware...........that's if you can. Sometimes there's firmware locks to prevent this.
IIRC at the time there were doubts the jitter issue could be masked with firmware but it was bad enough that I think a new record was set for the fastest FW release.