| Products > Test Equipment |
| REVIEW - Rigol DS2072 - First Impressions of the DS2000 series from Rigol |
| << < (380/566) > >> |
| Bugware:
I have just upgrade my device to the new Firmware 00.02.01.00.03. I had two Bugs with the old Firmware 00.01.01.00.02 and they are not solved. But I noticed, that the Screensave is now much faster! :) First Bug: The intensity graded waveform gets bright horizontal lines in the waveform when statistics is turned on: Second Bug When the trigger is change from DC Coupling to AC or HF Reject Coupling then the trigger point slips to the "left" about approx 2µs: An other Bug in Firmware 00.01.01.00.02 is now fixed. When in Time Base X-Y the Horizontal knob was pushed to delayed sweep "unavailable function" is displayed. But after change to Y-T Time Base the delayed sweep background is activated but not for the Waveforms. This Bug is now fixed. |
| marmad:
--- Quote from: Bugware on December 18, 2013, 05:59:18 pm ---First Bug: The intensity graded waveform gets bright horizontal lines in the waveform when statistics is turned on: --- End quote --- I'm not sure I would classify this as a bug or not. When you turn on Statistics, the waveform display area is reduced from 700x400 to 700x360 by the display processor before overlaying measurement stats. Those small horizontal lines you see are artifacts from the reduction (exactly 5 lines per div.) from 50 vertical pixels per div. to 45. Perhaps Rigol could fix this, but I'm SURE it would mean slower update rates for a smoother algorithm (which, IMO, isn't worth it). --- Quote ---Second Bug When the trigger is change from DC Coupling to AC or HF Reject Coupling then the trigger point slips to the "left" about approx 2µs: --- End quote --- As noted in my post right above yours, this bug is already in the list: #17. |
| Bugware:
--- Quote from: marmad on December 18, 2013, 06:36:47 pm --- --- Quote from: Bugware on December 18, 2013, 05:59:18 pm ---First Bug: The intensity graded waveform gets bright horizontal lines in the waveform when statistics is turned on: --- End quote --- I'm not sure I would classify this as a bug or not. When you turn on Statistics, the waveform display area is reduced from 700x400 to 700x360 by the display processor before overlaying measurement stats. Those small horizontal lines you see are artifacts from the reduction (exactly 5 lines per div.) from 50 vertical pixels per div. to 45. Perhaps Rigol could fix this, but I'm SURE it would mean slower update rates for a smoother algorithm (which, IMO, isn't worth it). --- End quote --- Sure that is a scaling problem. But I think all data in the display memory must be scaled?! So maybe there is no change in the update rate, so my thought... --- Quote from: marmad on December 18, 2013, 06:36:47 pm --- --- Quote from: Bugware on December 18, 2013, 05:59:18 pm ---Second Bug When the trigger is change from DC Coupling to AC or HF Reject Coupling then the trigger point slips to the "left" about approx 2µs: --- End quote --- As noted in my post right above yours, this bug is already in the list: #17. --- End quote --- I see. Sorry I have misunderstood the bug #17 in the list. So then this is only a confirmation of that. ;) BTW. the offset is not only with AC Coupling but also for LF and HF Reject Coupling... 8) |
| WVL_KsZeN:
Was wondering if anyone could confirm this bug aswell: If i use the test signal as input (1.000kHz) and change my timebase using fine adjust, the measurement go all weird (while they dont have to) - attach channel 2 (f.e.) to the test signal - press auto - you should now have a timebase of 200us - active frequency measurement (2nd in left menu) - it should read 1.000kHz - change timebase to 500us -> it still reads 1.000kHz - change timebase to 1ms -> it still reads 1.000kHz - change timebase to 2ms -> it still reads 1.000kHz - change timebase to 5ms -> it still reads 1.000kHz - change timebase to 10ms -> it still reads 1.000kHz - now, change the scale adjust from coarse to fine - change timebase to 9.350ms -> frequency reads 891.3Hz!!! now, this is way off (more than 10%) and doesnt have to be. on the screen, there's 14*9.35ms=130.9ms of data. In that time, there have been 130.9 oscillations. Maybe it's possible the scope is reading one oscillation more or less, but imo the max error should be /130.9 * 100% = 0.76% = (9.9924Hz to 1.0076kHz), not more than 10%! Using a slightly smarter algorithm, the error should be even smaller.. This is with the latest firmware. Can anyone confirm this? if i set the timescale one higher (9.4ms), the scope reads 1.064Khz, one lower (9.3ms) and it reads 1.075Khz, which is about the error I'd expect. Same thing happens on other timebases, f.e. on 5.450ms the reading is >8% off! Update : It also seems to depend on the numer op points being taken. on the 5.45ms timescale, the auto mem depth is set at 7.63Mpts when using only one channel. The reading is 917.4Hz When changing the mem depth manually, you get : 14kpts - 1.019khz 140kpts - 1.019khz 1.4mpts - 1.019khz 14mpts - 1.019khz 56mpts - 1.019khz so only the auto setting for the mem depth is way off.. isnt that weird? At a timescale of 7.05ms/division, I'm even getting a reading of 886.5Hz, which is more than 11% off.. this is at a mem depth of 9.87Mpts. Any other manual mem depth gives a reading of 1.013kHz.. |
| marmad:
--- Quote from: Bugware on December 18, 2013, 06:52:48 pm ---Sure that is a scaling problem. But I think all data in the display memory must be scaled?! So maybe there is no change in the update rate, so my thought... --- End quote --- There is the normal scaling done between sample memory and display memory. The scaling for statistics is clearly done after this (since it's doubling lines), as part of the overlay (adding measurements, screen icons, etc). --- Quote ---I see. Sorry I have misunderstood the bug #17 in the list. So then this is only a confirmation of that. ;) BTW. the offset is not only with AC Coupling but also for LF and HF Reject Coupling... 8) --- End quote --- Yes, I knew, but the bug clearly affects filtered triggers - so fixing it for one will likely fix it for all - but I added *filtered* to the bug description to make it clearer. |
| Navigation |
| Message Index |
| Next page |
| Previous page |