-
I played a bit with the improved FFT function (memory mode) implemented on last DS1000Z FW, and after some quirks i tried the same test condition used by Dave in its video about FFT on DSOs, one 1 Mhz carrier FM modulated (FM freq 5Khz, FM dev 500 Hz), but at lower amplitude level, 10 mVrms on 50ohm termination.
In attachment a spectrum shot taken with my best settings.
I already posted this elsewhere, but i think it could be usefull to gather here owners suggestions, test results and bugs report to provide Rigol with some directions to the improve the current implementation, of course if they are interested ....
-
from https://www.eevblog.com/forum/testgear/final-questions-before-i-get-my-first-oscilloscope/msg860481/#msg860481
thats it! 16Kpts FFT improvement from Rigol what can we say? thanks to you Rigol but not enough to STFU 1Mpts FFT fanboys... Rigol should google faster implementation of embedded FFT, their slow processing is not sooo Cooley-Tukey.
-
1Mpts FFT could be an overkill, i will be glad with at least 64Kpts if UI controls are well implemented.
Is there any kwon channel to contact Rigol, just to ask if exist margin for improvement ? -
i heard few people here with/have contact to them, in the other DS1000Z bug wishlist thread. for this FFT wishlist, very little to be desired, only just go as deep as you can without sacrificing update rate...
-
Hi
If you are going to really get them focused on FFT, get them to fix the bug in the sample clock first. That's going to be a problem no matter how many points you process.
Bob -
i thought they fixed the sample clock jitter long time ago...
-
- Rigol should google faster implementation of embedded FFT, their slow processing is not sooo Cooley-Tukey.
I do care a lot more to resolution and dynamic range, of course any improvement for update speed will be appreciated.
Here below my probably_hopeless wish list for FFT function on Rigol DS1000Z (and higher, of course) :
1) at least up to 64K FFT points variable resolution
2) fine sample rate control
3) fixed dedicated center freq. control knob
4) fixed dedicated span freq. control knob
5) FFT at full screen without time domain signal graph, it's better for eyes and does not waste CPU/FPGA cycle and I/O bandwidth
6) as option log vertical scale in dBm @ 50ohm
7) cursor peak level search
8 ) changing sample rate does note move central freq as it does right now
9) averaging function
10) some more digit for center freq. and cursor position
This wish list is not intended for the next gen DSOs (Zynq / CycloneV ? ), but for the current generation as a free upgrade for all loyal customers !
If Rigol unleash its devolpment rep. power, the dick & balls / jumping jack rabbit ** syndrome will definitely be a distant memory.
** tanks Dave, those terms were really funny !
-
I do care a lot more to resolution and dynamic range, of course any improvement for update speed will be appreciated.
i have a suspicion that due to their slow algorithm, they have to limit their sample count to some abysimal value like 16Kpts. if this is the case, increasing sample count will result in crawling turtle fft screen update. i cant think of any other reason with this 24Mpts machine... -
Compared to the previous implementation (dicks & balls, actually) current FFT seems pretty decent, in absolute still lacks in resolution and operability.
It would be an appreciable step ahead just changing paramenters control like i said in my wishlist, ie currently when you change the time base you throw away the center freq (so your signal) from the screen
Sure i would not expect miracles performance wise but i think that's possible to free some computing power disabling useless things like show on display time domain signal graph.
-
Sorry I might have been living under a rock, but which version of firmware has the improved FFT?
-
i thought they fixed the sample clock jitter long time ago...
Hi
Yes indeed they took care of an absolutely rotten jitter / phase noise / spur problem and turned the clock into something that is not quite as bad. The gotcha is that they still have "stuff" quite high up on the clock noise / spur wise. Dave has a spectrum plot in his video on the fix. That noise is going to be a big limiter on FFT.
Bob -
Looking closely at Dave's video https://www.youtube.com/watch?v=07VkEUUd0eo, starting from about 06:45 it's possible to roughly estimate the HMO1212's FFT trace update rate (vs selected number of points),
actually @16Kpt, the supposed new DS1000Z FFT resolution, the R&S scope is way faster than Rigol DS1054Z.
In order to compare the computing power inside both DSOs i gathered some specs on the web, here below a table listing CPU/FPGA used in DS1000Z and HMO1212 :
DS1000Z HMO1212
CPU MCIMX283DVM4B (ARM926 @454Mhz) ATSAMA5D31 (Cortex A5 @536Mhz)
FPGA SPARTAN-6 LX25 EP4CE30F
The SOC used in HMO1212 seems faster and the FPGA seems much capable, 3X internal RAM and 1.5-2X DSP math resources (first glance approximate suppositions
)
The FPGA ram difference may plays an heavy role on FFT performance, watching to boot time and UI responsivity it's clear that the R&S scope has the edge also at CPU side,
even if i guess that the RTOS chosen by R&S it's a lot more efficient.
So, just for fun, let's assume that the HMO1212 has twice the computing power of DS1054Z the actual FFT refresh rate ratio seems much higher.
I'm not considering of course code & platform efficiency, just wodering where is the bottleneck.
In attachment brief datasheet feature list extract for listed CPUs & FPGAs.
-
i thought they fixed the sample clock jitter long time ago...
Hi
Yes indeed they took care of an absolutely rotten jitter / phase noise / spur problem and turned the clock into something that is not quite as bad. The gotcha is that they still have "stuff" quite high up on the clock noise / spur wise. Dave has a spectrum plot in his video on the fix. That noise is going to be a big limiter on FFT.
Bob
It remains to see what other scopes (of the same market segment, please) have inside under this aspect, anyway i guess not on top of limiting factor list.
-
Sorry I might have been living under a rock, but which version of firmware has the improved FFT?
-
the problem with rigol is too many people dicking around with it. people ask too much to their desire thinking rigol can satisfy everybody. now we are going to the nitty gritty detail of how a sampling is performed in a dso. i read a pdf in the net, agilent iirc about how we live in imperfect world that no sampling module can perfectly sample at absolute perfect dT everytime, this will affect anything on the output you name it, FFT, interpolation, jitter, noise thd analysis etc.. you want perfect, pay premium... yes i will look forward Dave to measure spectrum of other DSO's clock, then we can judge which one is the most perfect clock apple to apple...
It remains to see what other scopes (of the same market segment, pleasei thought they fixed the sample clock jitter long time ago...
Hi
Yes indeed they took care of an absolutely rotten jitter / phase noise / spur problem and turned the clock into something that is not quite as bad. The gotcha is that they still have "stuff" quite high up on the clock noise / spur wise. Dave has a spectrum plot in his video on the fix. That noise is going to be a big limiter on FFT.
Bob) have inside under this aspect, anyway i guess not on top of limiting factor list.
-
I do care a lot more to resolution and dynamic range, of course any improvement for update speed will be appreciated.
i have a suspicion that due to their slow algorithm, they have to limit their sample count to some abysimal value like 16Kpts. if this is the case, increasing sample count will result in crawling turtle fft screen update. i cant think of any other reason with this 24Mpts machine...
They might be doing it on the main CPU where other scopes are doing it in an ASIC/FPGA.
-
the problem with rigol is too many people dicking around with it. people ask too much to their desire thinking rigol can satisfy everybody. now we are going to the nitty gritty detail of how a sampling is performed in a dso. i read a pdf in the net, agilent iirc about how we live in imperfect world that no sampling module can perfectly sample at absolute perfect dT everytime, this will affect anything on the output you name it, FFT, interpolation, jitter, noise thd analysis etc.. you want perfect, pay premium... yes i will look forward Dave to measure spectrum of other DSO's clock, then we can judge which one is the most perfect clock apple to apple...
It remains to see what other scopes (of the same market segment, pleasei thought they fixed the sample clock jitter long time ago...
Hi
Yes indeed they took care of an absolutely rotten jitter / phase noise / spur problem and turned the clock into something that is not quite as bad. The gotcha is that they still have "stuff" quite high up on the clock noise / spur wise. Dave has a spectrum plot in his video on the fix. That noise is going to be a big limiter on FFT.
Bob) have inside under this aspect, anyway i guess not on top of limiting factor list.
Hi
Take a look at the spectrum in the video. Check out the sidebands that he finds before and after the fix. Trust that Dave knows what he's doing. Trust that the checks he performs on his probes are valid.
Assuming that all passes the sniff test, build up a PLL using that specific Analog Devices chip. Feed it into a spectrum analyzer (or better yet a phase noise analyzer) and see what sort of sidebands you get with a proper set of R's and C's in the filter. Been there done that (in a product). What they are getting is way less than that chip can produce with the right values attached.
Is the world ever so simple that a quick look at a video gives you 100% confidence in a fix? Never ever. There are a half dozen odd things that could be messing things up other than the loop filter parts. I suppose it is possible that Dave's data is not perfect. That said, I would place about 80% odds on the filter having the wrong values in it.
What is sure is that with those sort of sidebands on the clock, you will have an impact on an FFT. The clock running properly likely has a sub 10 ps jitter. That's a lot better than they need for normal scope stuff. If the crud takes the jitter (in some arbitrary bandwidth) up to a few hundred picoseconds, that's no big deal for the main display process. Even a nanosecond or two might be ok for the display. Stuff that is 30 to 50 db down is *not* a good thing for a FFT.
Bob -
They might be doing it on the main CPU where other scopes are doing it in an ASIC/FPGA.
i dont care actually, i'm more than happy already. with the same price as my older DS1052E, in Z i have intensity graded 30KWfm/s update rate selectable 24Mpts max deep memory, these 2 things alone is enough to make me big smile, not to mention 4 channels. just looking at intermitent/jittering signal on this 30KWfm/s intensity graded is just awesome, several light years ahead of my ol' DS1052E. for me, i just congratulate Rigol for pushing beyond the limit, nice modern GUI and all... granted other scopes are doing in FPGA, but at double the cost, its a no brainer for me... for what i know, other brands are crawling to catch up with Rigol's spec and pricing... -
I do care a lot more to resolution and dynamic range, of course any improvement for update speed will be appreciated.
i have a suspicion that due to their slow algorithm, they have to limit their sample count to some abysimal value like 16Kpts. if this is the case, increasing sample count will result in crawling turtle fft screen update. i cant think of any other reason with this 24Mpts machine...
They might be doing it on the main CPU where other scopes are doing it in an ASIC/FPGA.
I too think that's the case and here the main cpu is also managing directly the lcd panel with its integrated controller, where the DS2000A uses a dedicated SPARTAN 6 FPGA, that probably takes care of math functions too, maybe also FFT.
Against the R&S HMO we have a clear FPGA weakness, nothing bad at all considering the price ratio, but still remain the doubt where the FFT effort is done.
If only the source code was loaded on GitHub ... LOL !
-
If only the source code was loaded on GitHub ... LOL !
If Rigol really wanted to kill the opposition forever, that would be the way to go. I'm sure there's plenty of people out there who could optimize the code and extract a lot more from the hardware.
And I could fix some of the UI nasties.
-
If only the source code was loaded on GitHub ... LOL !
If Rigol really wanted to kill the opposition forever, that would be the way to go. I'm sure there's plenty of people out there who could optimize the code and extract a lot more from the hardware.
And I could fix some of the UI nasties.
As far as you know, there are precedents for DSO's public source code ? -
If Rigol really wanted to kill the opposition forever, that would be the way to go.
no this is just a delusional ideology. you make your code open, everybody is doing it, no business for you. and worst, gwInstek will take the code, improve more on the GUI, add bell whistle here and there, and killed the "sourcerer". the only reasonable reason to make your source code open is if you want to make a free social work...As far as you know, there are precedents for DSO's public source code ?
i bet my bottom dollar if there is, it will looks like a blob fish, 16x4 characters at best...