Yes I have already and as I mentioned there, the BW upgrade is not working for my DHO1104. That is why I am asking.
Then I would put the question in the hacking thread, because that's what it's there for.
Here it goes under.
The DHO1000 I received has been sitting around for almost a year, cal print date of 11/2022. Definitely not a top seller. Could even be some of the first NA production batch.
edit: 46W power consumption on, 1.2W when off.
The math functions IMO are actually quite decent -- admitted, a free math formula entry mode would be preferrable but since there are four possible math windows available, one can do pretty decent stuff with them. Moreover, they are also reasonably fast. As an example for the accuracy, I added screenshots of a PRBS signal first integrated and then differentiated again and then vice versa.
As a peculiar sidenote, it's obvious that Rigol calculates the math in the Zoom window independently of the main trace, easily to be seen in the last screenshot where the trace has been shifted slightly so the first derivative peak goes negative and thus shifts the whole integration trace down vs. the main window. But the accuracy of the reproduction of the original trace is quite satisfying.
No way this kind of precision could have been reached with Rigol's legacy scope's math engines...
The detented optical encoders (used for input sensitivity and timebase) that Rigol "hyped" so much for longevity in their ads are crap! Either this or Rigol's engineers still didn't learn how to program such an encoder interface properly (which may very well be possible but is equally embarrassing for them):
While the timebase adjustments work more or less correctly on my black-friday DHO1000, the input sensitivity encoder works okay when turning clockwise, in the counterclockwise direction it frequently skips an increment between two detents and changes the value by two increments upon the next detent.
These encoders have either two or four phase changes between two detents, and at least one phase change happens close to the detent positions (but may slightly be offset to either side) while the other happens approx. half-way in between the detents. And obviously the latter phase change is the one that the increment/decrement of the adjustable value should be synchronized on.
I found this annoying behaviour already on my (almost a decade old) DG4000 AWG. Seems like Rigol hasn't learned anything since!
And the worst thing about this is that it (most likely) cannot be corrected by firmware update since the front panel PCB contains its own Microcontroller / PLD that manages all the LEDs, pushbuttons and encoders and converts their status into a serial data stream. Apparently, this device needs to be programmed via its own ICSP connector!
I will receive mine in 2-3 days. I will inform here if the optical encoders have the same issue or not.
Prices are the same here in Canada but some models are not in stock for immediate shipment.
While the timebase adjustments work more or less correctly on my black-friday DHO1000, the input sensitivity encoder works okay when turning clockwise, in the counterclockwise direction it frequently skips an increment between two detents and changes the value by two increments upon the next detent.
I can't reproduce the same issue, you are talking about turning the V/mV dial counter clockwise right?
I had one time where it detented and I didn't see a value change, but that was after about 10 turns back and forth with seemingly normal behavior, and may have been my imagination. If I speed turn the dial either direction there is no obvious odd behavior.
The only minor thing I noticed is if you are already at 500uV and turn the dial to go lower, the waveform will clear and sometimes glitch with spikes, though there won't be a trigger off of them. The previous mso5000 would pop up "over limit", this one doesn't which is fine.
My DHO1074 was delivered, ordered from rigol.eu
firmware : 02.04
hardware : 2
build : 2022/12/14
calibration date : 2023/3/28
The offer include the free RLU-01 option, but is not activated, and in the box there is no key for it. I asked them by email, until now I have no reaction.
The encoders are working "almost" fine. Sometime the behavior is like TurboTom said ... it skip some detents and the next is "doubled". But for me the timebase is the problem, the input sensitivity is OK. Can't be reproduced all the time, and not the same detent. I hope that is a problem of software.
I will update the firmware and will see.
Just got mine 1072 from rigol.com.pl
Hardware 9
Firmware 2.04
Options unlocked, Upgraded to 2.12
Noise 200Mhz inputs shorted, DC 1ms/div 2GSa/s 100Mpts 1mV/div:
575uVpp 105uV ACRMS normal mode
375uVpp 58uV ACRMS 14-bit mode (50MHz BW)
296uVpp 26uV ACRMS 16 bit mode (25MHz BW)
Noise 20Mhz inputs shorted, DC 1ms/div 2GSa/s 100Mpts 1mV/div:
262uVpp 23uV ACRMS normal mode
238uVpp 21uV ACRMS 14-bit mode (50MHz BW) this is what scope writes, looks incorrect because BW is already 20Mhz
222uVpp 19uV ACRMS 16 bit mode (25MHz BW) this is what scope writes, looks incorrect because BW is already 20Mhz
Dave's setting from the video
Noise 200Mhz inputs shorted, DC 1ms/div 50MSa/s 1Mpts 1mV/div:
661uVpp 69uV ACRMS normal mode
252uVpp 28uV ACRMS 14-bit mode (1.25MHz BW)
192uVpp 22uV ACRMS 16 bit mode (625kHz BW)
Noise 20Mhz inputs shorted, DC 1ms/div 50MSa/s 1Mpts 1mV/div:
237uVpp 24uV ACRMS normal mode
108uVpp 12uV ACRMS 14-bit mode (1.25MHz BW)
90uVpp 10uV ACRMS 16 bit mode (625KHz BW)
The scope is not grounded, after I connected the ground the noise values not changed.
Indeed, noise level is very low.
1mV/div, 2 channels, 50 Ohm terminators on inputs, BW 20MHz / 200MHz, memory auto / max.
For me ch 1 have the highest bias, and ch 4 the lowest.
Also, some pictures for StairUp signal, 6mVpp, 1MHz. Acquisition normal, HiRes 14 bit (50MHz BW), HiRes 16 bit (BW 25MHz).
Generator SDG2042X.
Also, some pictures for StairUp signal, 6mVpp, 1MHz. Acquisition normal, HiRes 14 bit (50MHz BW), HiRes 16 bit (BW 25MHz).
Generator SDG2042X.
So the reduced bandwidth in 14 and 16 bit mode is independent of the sampling rate? The 50 and 25 MHz you state for your data, taken at 2 GSa/s, are the same as what ZhuraYuk quoted, for measurements taken at only 50 MSa/s.
I would have thought that they need to reduce the bandwidth if the base sampling rate is already low, to account for the averaging/interpolation/whatever needed to get the extra bits. But if you start with 2 GSa/s, shouldn't there be enough headroom to get higher resolution without sacrificing bandwidth right away?
Also, some pictures for StairUp signal, 6mVpp, 1MHz. Acquisition normal, HiRes 14 bit (50MHz BW), HiRes 16 bit (BW 25MHz).
Generator SDG2042X.
So the reduced bandwidth in 14 and 16 bit mode is independent of the sampling rate? The 50 and 25 MHz you state for your data, taken at 2 GSa/s, are the same as what ZhuraYuk quoted, for measurements taken at only 50 MSa/s.
I would have thought that they need to reduce the bandwidth if the base sampling rate is already low, to account for the averaging/interpolation/whatever needed to get the extra bits. But if you start with 2 GSa/s, shouldn't there be enough headroom to get higher resolution without sacrificing bandwidth right away?
I've checked. There are the BW vs Sample rate :
2GSa/s : 14bit/50MHz; 16bit 25MHz
1GSa/s : 14bit/25MHz; 16bit 12.5MHz
500MSa/s : 14bit/12.5MHz; 16bit 6.25MHz
... and so on
Later edit : for 50MSa/s I have 14bit/1.25MHz, 16bit/625kHz. So I believe it was a typo / copy-paste error.
Indeed, noise level is very low.
1mV/div, 2 channels, 50 Ohm terminators on inputs, BW 20MHz / 200MHz, memory auto / max.
For me ch 1 have the highest bias, and ch 4 the lowest.
Also, some pictures for StairUp signal, 6mVpp, 1MHz. Acquisition normal, HiRes 14 bit (50MHz BW), HiRes 16 bit (BW 25MHz).
Generator SDG2042X.
Looks like the noise floor is different depending on the model. I have 23uVrms in mine DHO1072 vs 17uVrms in your DHO1074. Or mine is faulty.
Need more people with DHO1072 to compare the results
I've checked. There are the BW vs Sample rate :
2GSa/s : 14bit/50MHz; 16bit 25MHz
1GSa/s : 14bit/25MHz; 16bit 12.5MHz
500MSa/s : 14bit/12.5MHz; 16bit 6.25MHz
... and so on
Later edit : for 50MSa/s I have 14bit/1.25MHz, 16bit/625kHz. So I believe it was a typo / copy-paste error.
Ah, thanks! That makes a bit more sense. Although the initial bandwidth reduction to get to 14 bits still seems "excessive", and the next step to 16 bits seems "too small" -- can't get an extra two bits by just halving the sample rate.
So maybe the bandwidth reduction it is not only driven by the sampling requirements, but the scope low-pass filters the signal to reduce the noise in sync with the gain in resolution? Are the bandwidths the same at any V/div setting, or do you possibly get more bandwidth at lower sensitivity settings?
Looks like the noise floor is different depending on the model. I have 23uVrms in mine DHO1072 vs 17uVrms in your DHO1074. Or mine is faulty.
Sampling rate was not the same though. You had just one channel active at 2 GSa/s, while core ran two of them at 1 GSa/s. Maybe that explains some of the difference?
Just got mine 1072 from rigol.com.pl
Hardware 9
Firmware 2.04
Options unlocked, Upgraded to 2.12
Noise 200Mhz inputs shorted, DC 1ms/div 2GSa/s 100Mpts 1mV/div:
575uVpp 105uV ACRMS normal mode
375uVpp 58uV ACRMS 14-bit mode
296uVpp 26uV ACRMS 16 bit mode
Noise 20Mhz inputs shorted, DC 1ms/div 2GSa/s 100Mpts 1mV/div:
262uVpp 23uV ACRMS normal mode
238uVpp 21uV ACRMS 14-bit mode
222uVpp 19uV ACRMS 16 bit mode
Dave's setting from the video
Noise 200Mhz inputs shorted, DC 1ms/div 50MSa/s 1Mpts 1mV/div:
661uVpp 69uV ACRMS normal mode
252uVpp 28uV ACRMS 14-bit mode (50Mhz BW)
192uVpp 22uV ACRMS 16 bit mode (25Mhz BW)
Noise 20Mhz inputs shorted, DC 1ms/div 50MSa/s 1Mpts 1mV/div:
237uVpp 24uV ACRMS normal mode
108uVpp 12uV ACRMS 14-bit mode (1.25Mhz BW)
90uVpp 10uV ACRMS 16 bit mode (625kHz BW)
The scope is not grounded, after I connected the ground the noise values not changed.
Thanks for pointing out
core I edited original post with correct BW
Looks like the noise floor is different depending on the model. I have 23uVrms in mine DHO1072 vs 17uVrms in your DHO1074. Or mine is faulty.
Sampling rate was not the same though. You had just one channel active at 2 GSa/s, while core ran two of them at 1 GSa/s. Maybe that explains some of the difference?
I did exactly the same setup as on his screenshots later, with sample rate and everything identical. Still 23uV ACRMS noise floor.
Regarding the fans noise, it's not silent at all.
I have MSO5000, and I've been considered it noisy until now, but compared with DHO it's almost silent.
The level is higher, but also the spectrum freq is higher.
I've found an open source noise level apps, named Spectroid and I've made some measurements at about 1m in front of them.
I have attached some pictures, also one for reference, only a computer running in the room.
Also the available options.
Yeah, I will play around with Spectroid, to see if it can be used as a comparative tool.
Looks like the noise floor is different depending on the model. I have 23uVrms in mine DHO1072 vs 17uVrms in your DHO1074. Or mine is faulty.
Sampling rate was not the same though. You had just one channel active at 2 GSa/s, while core ran two of them at 1 GSa/s. Maybe that explains some of the difference?
I did exactly the same setup as on his screenshots later, with sample rate and everything identical. Still 23uV ACRMS noise floor.
Strage, we have to see an DHO1072 inside and compare with 1074 regarding the input stages.
If are the same, it can be a matter of luck regarding the cips installed.
Both channels have the same level of 23uV noise ?
Also, some pictures for StairUp signal, 6mVpp, 1MHz. Acquisition normal, HiRes 14 bit (50MHz BW), HiRes 16 bit (BW 25MHz).
Generator SDG2042X.
So the reduced bandwidth in 14 and 16 bit mode is independent of the sampling rate? The 50 and 25 MHz you state for your data, taken at 2 GSa/s, are the same as what ZhuraYuk quoted, for measurements taken at only 50 MSa/s.
I would have thought that they need to reduce the bandwidth if the base sampling rate is already low, to account for the averaging/interpolation/whatever needed to get the extra bits. But if you start with 2 GSa/s, shouldn't there be enough headroom to get higher resolution without sacrificing bandwidth right away?
For the moment I can't find an advantage for 14 or 16 bit, and where I can use them. I loose significant BW and details in low level signal.
The normal acquisition mode seems to be just fine.
Strage, we have to see an DHO1072 inside and compare with 1074 regarding the input stages.
If are the same, it can be a matter of luck regarding the cips installed.
Both channels have the same level of 23uV noise ?
Ch1 23uV Ch2 21uV. I see in your screenshot the channels have some slight dc offset where mine do not have that. I wonder if this is because of the firmware version or bad self calibration, I have 2.12.
Strage, we have to see an DHO1072 inside and compare with 1074 regarding the input stages.
If are the same, it can be a matter of luck regarding the cips installed.
Both channels have the same level of 23uV noise ?
Ch1 23uV Ch2 21uV. I see in your screenshot the channels have some slight dc offset where mine do not have that. I wonder if this is because of the firmware version or bad self calibration, I have 2.12.
I'm still testing it with the old version because I'll try to have a reference when I will update.
Where did you found the v2.12 ?
On line I see only 2.11
Anyway, you must calibrate after each update. The dc offset will be improved, but regarding the noise level I don't know.
And it's not a such big difference, even 23uV it's better than almost any scope on the market.
There are other things that are not very good (at all ...) on Rigol scopes, like FFT. And I have some questions regarding the trigger stability and serial decoders.
Indeed, noise level is very low.
1mV/div, 2 channels, 50 Ohm terminators on inputs, BW 20MHz / 200MHz, memory auto / max.
For me ch 1 have the highest bias, and ch 4 the lowest.
Hello,
Can you please make the measurements with 1 V/div instead of 1 mV/div?
Best regards
egonotto