| Products > Test Equipment |
| Rigol DS1000Z series buglist continued (latest: 00.04.04.04.03, 2019-05-30) |
| << < (52/74) > >> |
| Porcine Porcupine:
--- Quote from: frozenfrogz on March 05, 2018, 10:29:41 am ---Btw. if you are on the low end, say 10mV per unit, you are seeing all the noise. If you zoom in per time base, the "double trace" resolves into a scattered point cloud, showing kind of a rendering issue. The black area between the top and bottom "trace" should actually be all yellow in this case, but for some reason the individual dots add up to *null* when merged closely together. --- End quote --- In your screenshot with the point cloud, I believe it is displaying 600 points (50 ns * 12 divisions * 1 GSa/s = 600 samples) of raw data directly from the acquisition memory with no downsampling or other processing. The traces in all the other images you posted were downsampled, and I think something Rigol didn't intend is happening during that downsampling at some time base settings to create that gap in the trace. It looks like peak detect mode finding the minimum and maximum noise points to me, but it shouldn't be happening whatever it is. |
| Fungus:
--- Quote from: Porcine Porcupine on March 06, 2018, 05:39:03 am ---It also seems strange to me that noise or anything else in this signal could alias into two lines like that without any points between them. --- End quote --- So, you need to learn more about aliasing. Look at texture mapping in 3D graphics where the same problem occurs. When an object is far away then one pixel on screen might cover hundreds (or even thousands!) of pixels in the texture map. There's no way to downsample/filter it in real time. nb. In 3D graphics they solve it by using precomputed mipmaps for the textures but an oscilloscope can't do that. --- Quote from: Porcine Porcupine on March 06, 2018, 05:39:03 am ---When I downsampled with Matlab, I did it in about the crudest way possible by just throwing samples away without any low-pass filtering. If downsampling were going to cause such aliasing with this signal, don't you think it would have happened then? --- End quote --- Nope. What you see depends on the ratio of the high frequency components of the signal to the samples you kept. In the post I linked to there's 4 different views of the same data, all views are completely different. The difference you see on screen comes purely from the selection of which points were thrown away and which were kept. It's nothing to do with peak mode or anything else, that's a complete red herring. It's 100% due to the limits of the downsampling filter and it can't be fixed by a firmware update. (more correctly: it can't be fixed without reducing the screen update rate to something unacceptable). https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145 |
| Porcine Porcupine:
--- Quote from: Fungus on March 06, 2018, 08:00:25 am --- --- Quote from: Porcine Porcupine on March 06, 2018, 05:39:03 am ---It also seems strange to me that noise or anything else in this signal could alias into two lines like that without any points between them. --- End quote --- So, you need to learn more about aliasing. Look at texture mapping in 3D graphics where the same problem occurs. When an object is far away then one pixel on screen might cover hundreds (or even thousands!) of pixels in the texture map. There's no way to downsample/filter it in real time. nb. In 3D graphics they solve it by using precomputed mipmaps for the textures but an oscilloscope can't do that. --- Quote from: Porcine Porcupine on March 06, 2018, 05:39:03 am ---When I downsampled with Matlab, I did it in about the crudest way possible by just throwing samples away without any low-pass filtering. If downsampling were going to cause such aliasing with this signal, don't you think it would have happened then? --- End quote --- Nope. What you see depends on the ratio of the high frequency components of the signal to the samples you kept. In the post I linked to there's 4 different views of the same data, all views are completely different. The difference you see on screen comes purely from the selection of which points were thrown away and which were kept. It's nothing to do with peak mode or anything else, that's a complete red herring. It's 100% due to the limits of the downsampling filter and it can't be fixed by a firmware update. (more correctly: it can't be fixed without reducing the screen update rate to something unacceptable). https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145 --- End quote --- Thanks for the explanation, but I'm still a little confused about how such aliasing is happening. I'm interested in replicating the aliasing in Matlab from the raw data to understand it better. Do you have any suggestion on how I might do that? I downsampled by a factor of 2,000 to go from 2.4 million raw sample points to 1,200 like the oscilloscope presumably did to get the trace data but didn't get the aliasing. Would I perhaps see similar aliasing if I tried other downsampling ratios or different sampling phases? |
| Fungus:
--- Quote from: Porcine Porcupine on March 06, 2018, 10:05:55 am ---I downsampled by a factor of 2,000 to go from 2.4 million raw sample points to 1,200 like the oscilloscope presumably did to get the trace data but didn't get the aliasing. Would I perhaps see similar aliasing if I tried other downsampling ratios or different sampling phases? --- End quote --- You just described the problem perfectly: How do you reduce 2000 points of data to a single point on screen? I don't know what method the DS1054Z uses, sorry. I'm sure it's done in hardware though so expect it to be a compromise. :popcorn: (nb. The DS1054Z only displays 600 points on screen so there's a secondary 2:1 reduction somewhere...) |
| ebastler:
--- Quote from: Fungus on March 06, 2018, 10:30:53 am ---How do you reduce 2000 points of data to a single point on screen? I don't know what method the DS1054Z uses, sorry. I'm sure it's done in hardware though so expect it to be a compromise. --- End quote --- Obviously we don't know how it is implemented by Rigol. But I can't see a good reason for always showing the extreme data points, and hardly ever showing one with medium amplitude. That does hint towards an unintended peak-detect like algorithm, as postulated by porcupine. And, not to forget: At just slightly faster time base settings, where the scope still has to do massive down-sampling, the effect disappears and the curves or point clouds look reasonable. Something must go "wrong" at those slow time bases. Maybe some histogram counter overflowing or whatever? Anyway, this is just guessing. But I think it likely that, within the limitations of the existing DS1000Z hardware, there would be a better way to down-sample and display the signals at slow time bases. |
| Navigation |
| Message Index |
| Next page |
| Previous page |