Geez... And to think I trusted you. You little tinker
Yes, I didn't realize that other users might just try to replicate the results on their DSO - instead of just playing the file (which was so obviously stupid that I was sure it would be recognized as phony). I felt guilty for awhile... but did imagine withe some amusement the various attempts to select '*.trc'.
hehee
If Rigol gives me a SCPI command to control the frequency (and length) of the beep, I will make it play that tune when you start RUU!
DS2000-S will be definitely better (hardware) than DSOX2000. But when will it appear at www.silcon.cz ??
October/November this year is my rough guess.
Then Agilent guys will have to release a new firmware for DSOX2000 with new functions, for example arbitrary generator or advenced triggers... Who knows?
Í think the X3000 wave generator has arbitrary. Probably missing on the X2000 for a reason?
Back on topic. I received my DS2072 today. If I have understood it right, I shouldn't calibrate it if I want to keep the "trial options", meaning SPI/I2C decoding and so on?
Back on topic. I received my DS2072 today. If I have understood it right, I shouldn't calibrate it if I want to keep the "trial options", meaning SPI/I2C decoding and so on?
Yes - better to wait. Don't worry - there will be opportunities to calibrate a bit later when 'regenerating' trial options.
Hello,
is there a danger that one do the regeneration to late?
Best Regards
egonotto
is there a danger that one do the regeneration to late?
No - you can do it anytime.
Hello marmad,
thank you.
Best Regards
egonotto
Having heard back from Rigol (via our good friend Drieg), it appears I was mistaken about the following bug:
When both channels are on, any memory read that requires more than one packet of data will ALWAYS fail. The maximum packet size is around 2MB - so any memory depth >2MB for byte mode or >~200kB for ASCII mode can not be read correctly.In fact, it works fine. The thing that was confusing my software is that, with a single channel on, the two SCPI commands used to test and then read the buffer (:WAV:STATus? -> WAV:DATA?) both return the same number of bytes to be read from the DSO. But with two channels on, the commands return different numbers, with the WAV:DATA (not STATus) command containing the correct number (i.e. the DSO has filled it's buffer further after the STATus command).
So I've removed this bug from
the bug list - which, BTW, is reportedly down to virtual NIL in the upcoming release.
So I just got my DS2072 and teneyes ask me to post up info on my firmware and fpga etc... well here's what it shows...
He also asked when the last cal time was from the self cal menu and that is showing as 2011-01-01 00:00:00...
so what's the consensus on the most stable version for a noob to upgrade from 00.00.01
Well, it might happen. I bought my DSOX2002A in April 2013 as a new unit from Farnell. I got a scope manufactured in July 2012.
so what's the consensus on the most stable version for a noob to upgrade from 00.00.01
To get your correct FW version, read the bottom portion of
this post.
The self-calibration date is meaningless - it's just the earliest date/time stamp the DSO can show (i.e. no self-cal has been run); factory calibration data is not stored in the DSO - it's on a piece of paper that comes with the scope.
Thanks Marmad, I just saw there was a trick to show the detailed info... so here's that, i thought for some reason i had super old firmware version that possibly didn't show the detailed stuff. I'll carefully read over your great info. thanks for all your hard work, tried out your software really quick and it looks awesome so far.
I don't know how Farnell are still in business. Terrible prices, pathetic range, slow website with a useless search function, parametric searching which usually doesn't include the most important parameters... And apparently lots of old stock too.
LOL I'm not the only one that thinks so.
Oh, the price was not bad. It was cheaper than my local dealer
www.htest.cz
Since I had already gone so far as to almost create a full table in the other thread, I figured that I might as well finish it - so here it is for future reference:
Maximum number of segments which can be recorded at each sample length on the Rigol DS2000 series:
Following up my obvious need to make tables today:
DSO sample rate for each selectable sample length on the Rigol DS2000 series:
Back on topic. I received my DS2072 today. If I have understood it right, I shouldn't calibrate it if I want to keep the "trial options", meaning SPI/I2C decoding and so on?
Yes - better to wait. Don't worry - there will be opportunities to calibrate a bit later when 'regenerating' trial options.
is there a danger that one do the regeneration to late?
No - you can do it anytime.
This is interesting. I searched the thread for "regenerate", "regenerating", and "regeneration" and came up empty for what this is referring to. Maybe someone can post a link?
Or maybe, there's "nothing to see here" Edit: Found out "nothing to see here".
...we're not posting about the technique publicly...so far, it seems to have kept Rigol from taking steps to prevent it.
Understood, "nothing to see".
Hi Marmad,
Just checking to see if you know what the maximum number of measurements are that can be displayed at one time on the Rigol 2000?
Thanks, EF
I'm not Marmad, but I'll answer anyway...pardon me Marmad. The max number I read in this thread is 5 measurements, which is one more than the Agilent DSOX2000 series.