- Menu item for vertical position/offset, seems the only way to change this is via the knob. Perhaps an oversight?
PS: Oh! And thanks
6) Writing full memory to a CSV file takes an extremely long time. Write speeds seem to be about 0.15 MB/sec instead of the expected 10MB/sec or so.(fixed in 4.03)
Yes, of course - you have to make sure that the start bit appears on the left side of the screen. In your middle picture, you have moved the trigger point outside of the screen window, so the trace again starts with a partial, ill-defined data frame. But you don't have to calculate anything, do you? Just turn the delay time knob until the vertical "trigger" indicator is moved towards the far left of the screen, but still remains on screen. No need to know about the precise data rate or frame duration in advance.
The decode on delay seems to only decode the zoomed in part. I had a recent project at my day job where we were decoding RS422 data out of the data buffer. With 100's of bytes in each packet, it would have been very painful to have to align each screen.
6) Writing full memory to a CSV file takes an extremely long time. Write speeds seem to be about 0.15 MB/sec instead of the expected 10MB/sec or so.(fixed in 4.03)Are you sure that this got fixed? I've saved a 1MB file in 9 seconds on an usb disk. And I'm still waiting (25min+) for a 24Meg memory dump to finish... :/
- Menu item for vertical position/offset, seems the only way to change this is via the knob. Perhaps an oversight?
PS: Oh! And thanks
Thank YOU for all that!
I don't quite understand your wish list item for a vertical offset menu option. How exactly would that work? Doesn't this have to be a knob controlled function, or do you want to be able to type in offset in volts (or whatever the current units are)?
I noticed something today that is perhaps not exactly a bug, but perhaps more than a wish.
I grabbed a lot of sample data from an RS232 instrument. When I zoomed in, all the data that wasn't showing was "lost" until I zoomed out.
This is all with the same buffer of data (e.g., scope stopped):
...
It is stuff like this that makes the big sample memory less useful than you think it would be.
Wish List Items:
A) Full screen X-Y mode, the current display is tiny. Also, allow screen persistence to be set in X-Y mode.
Regarding the X-Y mode, I'm not able to set a math function as X or Y
Es X=ch1 and Y=ch1-ch2
I was playing with a circuit to display the transistor curves but without this option it is useless.
I can see the "math" trace in the upper part of the display, but it is not possible to select it as source.
Is it possible to add this in the wish list?
Bug:
When the scope saves CSV data from the "memory" (not from the screen), the increment value is not right and has to be changed manually (Rigol's BUG ?). You must edit CSV file manually and put there sampling rate^-1
Pictures here:
https://www.eevblog.com/forum/projects/rigol-ds1000z-csv-to-ltspice-(pwl)-parser-(testers-welcomed-!)/msg673153/#msg673153
edit: Please confirm somebody
I guess I've found Yet Another bug. .
Firmware 04.03
I guess I've found Yet Another bug. .
Firmware 04.03
I can not reproduce this on my scope with firmware 04.02. Is this due to hardware variation too?
I guess I've found Yet Another bug. See the screenshots below. The Math trace is displaced about 1 1/2 divisions to the right from where it should be. The amount of the error depends on horizontal position; near the left of the screen it's less than 1 division and near the right, over 2 divisions. I don't yet know the "minimum" set of conditions to reproduce this bug, but it happens for me at present when I am using all 4 channels, have Math set to CH1 x CH4 and timebase set to 500 ns/div. Acquire mode "Average". At other timebase and/or Acquire settings the Math trace looks correct horizontally.
(Also happens in "zoom" horizontal mode, with main timebase set to whatever and "zoom" window TB set to 500 ns/div.)
Yesterday when I tried it was unable to reproduce it on 4.0.2 with four channels and math AxB with your timebase setiings.
Rather than state I just don't ever get this fault, I now see it may be dependent on zoom. May I suggest that you provide a sequence of steps from a factory default set up? You may well find that more people have the fault that way, rather than us drawing false conclusions from an unrepresentative configuration. That seemed to be the case in the last bug you drew attention to, once we'd had the full config from factory reset more people were able to demonstrate the bug.
I guess I've found Yet Another bug. See the screenshots below. The Math trace is displaced about 1 1/2 divisions to the right from where it should be. The amount of the error depends on horizontal position; near the left of the screen it's less than 1 division and near the right, over 2 divisions. I don't yet know the "minimum" set of conditions to reproduce this bug, but it happens for me at present when I am using all 4 channels, have Math set to CH1 x CH4 and timebase set to 500 ns/div. Acquire mode "Average". At other timebase and/or Acquire settings the Math trace looks correct horizontally.
(Also happens in "zoom" horizontal mode, with main timebase set to whatever and "zoom" window TB set to 500 ns/div.)I confirm this bug with firmware v04.03
I hate it because this bug causes an erroneus math waveform to be displayed and it is hard to notice on non-sparse source waveforms.
With the other bugs you could see immediately, that there was something wrong (e.g. freeze) but with this one you might never know if you don't look closely.
This bug is insidious and means that you cannot trust your scope.
Bug:
When the scope saves CSV data from the "memory" (not from the screen), the increment value is not right and has to be changed manually (Rigol's BUG ?). You must edit CSV file manually and put there sampling rate^-1
Pictures here:
https://www.eevblog.com/forum/projects/rigol-ds1000z-csv-to-ltspice-(pwl)-parser-(testers-welcomed-!)/msg673153/#msg673153
edit: Please confirm somebody
See wish list item W, at the top of this thread, it's based on this, knows issue.