-
Is there a way to tell if my oscilloscope's FFT is HW or SW?
Posted by ballsystemlord on 04 Dec, 2022 01:06 -
Hello,
I'm an oscilloscope newbie, so go easy. Mine is an MSO5000 series scope. I'm curious if it's FFT is HW or SW. The official specs don't even mention the scope's FFT rate, which can be found in their description of their YT videos' dealing with FFT comparisons. It's FFT rate is 1Mpts.
Thanks!
-
It's FFT rate is 1Mpts.
Probably a typo.
Don't know if it is done in hardware or in software, but I do know that the 1Mpts is not expressing the rate
It is the number of samples the FFT is calculated on. The more samples used the smaller the frequency interval between the bins. Depending on the sample rate this gives the frequency resolution of the FFT. At 1GSa/s it means the bins are 1KHz apart. The highest one representing 500MHz and the lowest 0Hz. -
a) What's the difference in practice?
b) It's not a "real time" FFT if that's what you're thinking of by "rate".
-
Software running on hardware.
-
Software running on hardware.
Software always needs hardware, otherwise it is vaporware
I guess ballsystemlord is wondering if the FFT is done in the FPGA with a dedicated bit of hardware design or on the main processor with standard processor instructions.
The MSO5000 series does have multiple FPGA's, so it could be that they made it in hardware. -
Quote
Don't know if it is done in hardware or in software, but I do know that the 1Mpts is not expressing the rate
I had thought that Mpts stood for Mega PoinTs per Second, much like MBs (MegaBytes per Second).
So, that leaves me wondering about both things. What the update rate is, and whether or not the FFT is done in HW or SW.
-
So, that leaves me wondering about both things. What the update rate is, and whether or not the FFT is done in HW or SW.
The 'update' rate, if by that you mean the screen refresh rate, will vary according to the timebase settings that you use for capture. The 1 megapoints means that it uses 1 million samples for the FFT calculations, but how long it takes to collect them depends on that timebase. There is a maximum update rate that will be determined by how long it take to do the FFT calculations on each capture, but I don't recall ever seeing that listed anywhere. It is not real time.
As far as HW vs SW, is an FPGA hardware or software once it is set up and doing its thing? AFAIK they don't use an FFT ASIC or anything like that. -
So, that leaves me wondering about both things. What the update rate is, and whether or not the FFT is done in HW or SW.
The 'update' rate, if by that you mean the screen refresh rate, will vary according to the timebase settings that you use for capture. The 1 megapoints means that it uses 1 million samples for the FFT calculations, but how long it takes to collect them depends on that timebase. There is a maximum update rate that will be determined by how long it take to do the FFT calculations on each capture, but I don't recall ever seeing that listed anywhere. It is not real time.
I understand the screens refresh rate will limit the update rate.
What I was interested in here is, "Is the FFT implementation able to keep up with the screen refresh rate and date being fed into the oscilloscope?"
For example, if the screen refreshes at 60Hz (it probably is), will I get 60 FFT updates per second or will I get only 1 update every second?
Here you can see that many of the screens seem to take a second to update even once: https://youtu.be/07VkEUUd0eo (Offset 50 seconds.)
Now maybe it's just that there's a pure signal being fed into the scopes so the screen, although it updates, it never needs to change. So I can't see a difference.
Second, will the scope ignore samples going into it in order to speed up the FFT function, or can the HW/SW keep up?As far as HW vs SW, is an FPGA hardware or software once it is set up and doing its thing? AFAIK they don't use an FFT ASIC or anything like that.
Much like a DRAM chip holds SW but doesn't run the SW, the same applies here. The FPGA is HW that is programmed via SW but doesn't run SW. At least AFAIK.
-
I understand the screens refresh rate will limit the update rate.
No.
The system has to crunch the FFT maths which accounts for the time it takes to sweep the full frequency set which is NOT related to the display update rate at all.
However this can be dramatically improved by reducing the FFT Mpts to some lower setting that still gives the results you seek but speeds the FFT sweep. -
The FPGA is HW that is programmed via SW but doesn't run SW. At least AFAIK.
FPGA is a box of logic blocks that can be configured to do many tasks. Among these tasks can be a processor, which can run software instructions just like a normal CPU.
When FFT functionality is configured into a FPGA it most likely performs the calculations in a loop due to the limited amount of DPS blocks a FPGA might have. Basically very much like it will be done in a processor, but might be a bit more optimized with parallel operations.
A FPGA is a very versatile piece of logic, yet still has limitations to what it can do and how fast it can do it. Calculating a 1Mpt FFT takes its time, and like bdunham7 wrote so does taking 1M samples. The latter depends on the sample rate, and the former on the speed of the CPU or FFT FPGA implementation. -
I understand the screens refresh rate will limit the update rate.
What I was interested in here is, "Is the FFT implementation able to keep up with the screen refresh rate and date being fed into the oscilloscope?"
For example, if the screen refreshes at 60Hz (it probably is), will I get 60 FFT updates per second or will I get only 1 update every second?
I wasn't referring to the screen refresh rate of the physical display, but rather the refresh rate of the FFT display on the screen. That may seem confusing, but it was clear in my mind at the time...QuoteSecond, will the scope ignore samples going into it in order to speed up the FFT function, or can the HW/SW keep up?
Not sure what you mean exactly by 'ignore samples'. There will obviously be a lot of blind time, as there is for almost all DSO functions. If the FFT is set for 1Mpts, the scope will collect a million (220 actually) points at whatever timebase and sample rate is selected and put them in a buffer. Then it will perform the FFT calculations on that set of points. Then it will display them on the screen, rinse and repeat. Some parts could overlap if it uses alternating buffers. It takes a certain amount of time to collect the million points (this varies with settings) and then a certain amount of time to process them. Those together determine how quickly it can refresh the FFT display. You can change the timebase settings and reduce the number of FFT points from the maximum, both will affect the FFT refresh rate.QuoteMuch like a DRAM chip holds SW but doesn't run the SW, the same applies here. The FPGA is HW that is programmed via SW but doesn't run SW. At least AFAIK.
Hmmmmm. Not sure I buy the DRAM analogy, but if you consider the FPGA to be 'hardware', then perhaps your scope is running the FFT in hardware. I'm not sure of the point of making the distinction. Suppose I program an FPGA to emulate a CPU and then run software on that? -
Got it.I understand the screens refresh rate will limit the update rate.
What I was interested in here is, "Is the FFT implementation able to keep up with the screen refresh rate and date being fed into the oscilloscope?"
For example, if the screen refreshes at 60Hz (it probably is), will I get 60 FFT updates per second or will I get only 1 update every second?
I wasn't referring to the screen refresh rate of the physical display, but rather the refresh rate of the FFT display on the screen. That may seem confusing, but it was clear in my mind at the time...
"ignore samples" (Again, if my understanding is off, please correct me...)QuoteSecond, will the scope ignore samples going into it in order to speed up the FFT function, or can the HW/SW keep up?
Not sure what you mean exactly by 'ignore samples'. There will obviously be a lot of blind time, as there is for almost all DSO functions. If the FFT is set for 1Mpts, the scope will collect a million (220 actually) points at whatever timebase and sample rate is selected and put them in a buffer. Then it will perform the FFT calculations on that set of points. Then it will display them on the screen, rinse and repeat. Some parts could overlap if it uses alternating buffers. It takes a certain amount of time to collect the million points (this varies with settings) and then a certain amount of time to process them. Those together determine how quickly it can refresh the FFT display. You can change the timebase settings and reduce the number of FFT points from the maximum, both will affect the FFT refresh rate.
Let's say that my scope can FFT 1Mpts in 1 second. Because my scope collects 8 GS/s, that would mean that in one second, I'd have performed the FFT function on 1Mpts and "ignored" 7,999 mega samples. Right?QuoteMuch like a DRAM chip holds SW but doesn't run the SW, the same applies here. The FPGA is HW that is programmed via SW but doesn't run SW. At least AFAIK.
Hmmmmm. Not sure I buy the DRAM analogy, but if you consider the FPGA to be 'hardware', then perhaps your scope is running the FFT in hardware. I'm not sure of the point of making the distinction. Suppose I program an FPGA to emulate a CPU and then run software on that?
Well sure you can make the FPGA perform like a CPU, and many other SW controlled stuff. The point of buying an FPGA, instead of a plain CPU, and placing it into an oscilloscope, is so that you can do something using the FPGA's HW to crunch data vs. using SW on a CPU, right?
Edit: I originally said 6GS/s. That was incorrect.
-
Let's say that my scope can FFT 1Mpts in 1 second. Because my scope collects 6 GS/s, that would mean that in one second, I'd have performed the FFT function on 1Mpts and "ignored" 5,999 mega samples. Right?
Sure, I suppose, but those 1Mpts could be from a short, consecutive capture at full speed or from a decimated capture over the full second. To make it easy, lets say you have a 1GSa/s scope. You can capture all the samples for 1 millisecond or you can capture every thousandth sample for the full second. That's a matter of settings. If you want to look at lower frequencies, you need the longer capture time at a lower rate. -
For example, if the screen refreshes at 60Hz (it probably is), will I get 60 FFT updates per second
Probably not.
-
........................
Hi.
It is nice to see when someone tries to understand and learn.
Let me first "kind of answer" the original question: MSO5000 (like many new-ish scopes) does FFT partially in FPGA (it crunches some preliminary data) and then data is fed to application processor (CPU) that in a role of DSP does final calculations and scaling. Where the actual partitioning lies depends from scope to scope.
About FFT itself: you perform a FFT over a certain data set (length). You need to capture data first, so that takes time. Then you calculate and display. If you want good frequency resolution (small frequency bin width) you need more (longer data). If you want to go to higher frequency you sample faster, which is again more data for same time period.
So sometimes you will have 1 FFT update per second although hardware accelerated FFT performs calculations in 1 ms. Why? Because you needed to wait 1 second for data to be captured..
That latency has to be accounted for. In this case this latency will dominate screen refresh rate.
How much time it takes depends on time base /sampling rate/FFT length interaction.
Secondly, FFT will be performed over exactly the amount of data it says. So if there is more in scope buffer, it will be ignored by FFT. It should be defined in User manual what it actually does. Some scopes will let you choose where from the buffer it will take data for FFT, so you can show spectrum from different parts of changing signal on screen. Some will simply chose some data from a buffer in a manner prescribed in manual.
There is something called sliding window FFT (sometimes called overlapped FFT). It works on pipeline principle, it has initial latency waiting for ADC sampling until sample is long enough and then performs FFT on that and displays it. Then it discards 1 latest sample and adds 1 new one and then again performs FFT. Latency here is one sample period, and therefore real time. This is used in real-time spectrum analysers. You can discard block of 10 or 100 and add that much new ones too.. That defines time period between spectrum plots..Spectrum waterfall or 3D plot display would be used to display it too..
There are some (higher end) scopes that have this capability. These will provide very fast screen updates but need specialized architectures in hardware to support it. Calculation is not so much a problem (although it needs to be beefy to handle it), but pumping all that data real time in parallel with normal scope functions..
Also I would recommend to read about windowing. It is a practice of "tapering off" beginning and end of sample buffer to account for discontinuity of data at data buffer ends. That is, because, the FFT should be performed on whole periods of repeating signal (starting from 0 and returning to 0 on the end). Since sample fixed periods with ADC, beginning and end of outside world signals will be "chopped off" wherever it pleases, so we need to deal with these untidy ends.
For that we use different shapes (windowing functions) to "cutoff ends" and "taper them from 0 to 0 at the ends". That makes spectrum to be cleaner but they each have different side effects that user should be familiar with.
Hope this helps .
Best, -
bonjour
check définition of " real time" signal processing the FFT
a moment please for a historic note....
Joseph Fourier invented the Fourier Series in 1807. Then the Fourier Transform. In 1960 Cooley and Tukey at BTL created the fast Fourier Transform, computation time was proportional to # points,rather than to # points squared.
At work, 1968..1971, we had a Nova 800 and custom boards that could render 103024 points FFT in 1mS
Enjoy
Jon
-
To avoid confusion, time complexity for N points:
- "Naive" discrete Fourier transform (DFT) is indeed quadratic O(N^2).
- Fast Fourier transforms (FFT) like Cooley/Tukey are actually O(log(N) * N). For example going from a 1024 point FFT to 1 Mpt may take ~10000 as many operations (still a 100 times improvement!). This is what most oscilloscopes will use (either in software or FPGA/ASIC accelerated). More sophisticated forms of FFT may be used for "spectrum analyzer" apps that allow you set the span independently (Bluestein's algorithm allows "zooming-in" on an area of interest) but they are broadly in the same category.
- Sliding DFT can actually be linear O(N) for the update step (shifting the window). But you need to compute one full FFT first to get you started. And applying window functions in the usual way doesn't work. May be used for "real-time" spectrum analysis on higher-end models.