I have made a proof of concept for adding FFT (spectral analysis) to the DSO Nano. The code is based on version 3.11 (the latest open source code).
The change is limited to the file “function.c”, where three functions are added. Furthermore, I have used assembler routines from the company Embedded Signals (see embeddedsignals.com).
The code calculates a 128 elements FFT, resulting in displaying 64 requency bins.
More work has to be done to make this a full feature on the DSO Nano, e.g.:
switch FFT mode on/off (now FTT is always displayed in the left side of the screen);
switch vertical scale to linear/log scale (now a log scale is used);
use horizontal cursor to display frequency/amplitude of FFT;
add peak-hold function;
increase number of bins (probably some memory overlay is needed to free memory).
Enjoy this prototype! Everyone is welcome to improve this code, possibly ending up in some future BenF version.
Files included in the zipfile:
Ei_FFT128Real32b.s (function FFT128Real_32b)
Ek_magnitude.s (magnitude32_32bIn)
Ei_log2.s (function log2_16q16)
Function.c (modified for FFT)
APP.dfu & LIB.dfu (executable) FFT.zip (41.6 KB)
Btw, would it be possible to draw it in the background in a different color, maybe with transparency? So you can watch it at the same time as you use the oscilloscope? Maybe the CPU power is not enough for that?
CPU power is not a problem.
The FFT signal is drawn in another color than the waveform (sorry for the bad photo with wrong colors). My first try was to draw the FFT on top of the waveform (in another color). However, when the number of waves in the waveform is high, the two signals (FFT and wave) can not be seen clearly anymore. Therefore, I changed the code so that the left part of the screen is used for the FFT.
Well done Paul. You have started this off very nicely. Thank you for posting it in this half finished state, and I see you have left code in which is not yet working (like the screen flickering) for us lesser mortals to start trying to fix.
Can I just check what is needed to start editing and re-compiling? I have IAR workbench v6.0
I loaded Benf’s 3.11 project in EWARM (DS0201_APP.ewp) and replaced BenF’s function.c with yours, and added your other 3 source files to the project.
In recompiling the project, all seems to work till I get to these two errors (note I am accessing a Mac filing system from within Parallels/Windows XP, but everything seems to be seen OK) :
“Fatal Error[Lc002]: could not open file “D:\My Documents\DSO BenF v3\DSO BenF v3\DS0201_APP\project\EWARM\stm32f10x_flash.icf”
Error while running Linker”
note the requested file is present. Perhaps IAR workbench stores file name addresses in different ways for different parts of the compiling/linking operations.
Any advice gratefully received - ps I am a bit of a novice with this ARM workbench, so probably have a long way to go before I can use it successfully.
Tony
I dont know know if the 3.11 can be compiled by IAR6.0, but you can download the 3.13 ,I have compiled it by IAR6.0: github.com/Seeed-Studio/DSO .
as the “stm32f10x_flash.icf”, i suggest you re-select it in you project, you may put it in a different place as the setting.
Thank you for the code in “http://gitorious.org/dsonano/dso-firmware” - it worked - I was able to add the FFT code and create a dfu file for the app. I uploaded it to my NANO and it worked like your original.
I also tried HugeMan’s link “https://github.com/Seeed-Studio/DSO”
On first loading this it showed "Broken option for tool “General” and on compilation throws up 210 errors and 16 warnings.
Many of the errors are from the assembler concerning MOVW, MOVT and MOVS - Error[438]: This instruction is not available in the selected cpu/core.
I can’t see where a different cpu/core can be selected - I thought that was just in the include files.
The warnings are Warning[Pa050]: non-native end of line sequence detected (this diagnostic is only issued once).
Anyway, there seems to be a compatibility problem which I dont understand with this version of the code.
Tony
I tested with downloading from the Seeed github link and was able to compile on IAR6.1 without errors. I did get the warnings (Pa050) however and this appears to be an issue with improper line termination (CR/LF vs. LF only). HugeMan may need to look into this as what was submitted to him compiled without hiccups of any kind.
We may also be in for some version confusion now as there are two github sites with Nano firmware sources as well as one Google code site with obvious overlaps. I can also envision it being difficult for a new Nano owner to locate and find pre-compiled firmware and assess what to use. Unless confusion is the strategy here, some consolidation and cleaning up may be in order.
Is this github code the 3.13 that BenF said somewhere he had given to Seeed Studio? Is there any announcement about this, or release notes? Are you (HugeMan) from Seeed Studio? Is the license the same as the 3.11 BenF code drop? Sorry for the flood of questions
The github repo does not have any history, but I will see if I can diff it against the 3.11, and merge those changes into the gitourious tree. As long as the license is compatible, of course.
I have been thinking of making a FFT branch on gitorious, but the FFT code is non-free so it complicates things. It also seems a bit tricky to get it to build on gcc, the code uses some compiler-specific instructions, and my first attempts have failed to run correctly. Maybe Paulvzz can consider maintaining his own FFT branch, and merge in any changes from my tree as they happen. So that there is no confusion that my tree will always be free software.
strang, I rebuild the two projects just now,but i found no errors and warnings.
We are considering realease our opensource firmware in github (Seeed-Studio), and we will dedicate to clean up the version confusion recently…as you said.
The assember routines from Embedded Signals are available for different compilers (Keil, IAR, GCC). The attached zipfile contains them all. The second letter (k, i or g) of the filename determines the compiler (Keil, IAR, GCC). FFT128real32.zip (25.8 KB)
your FFT is really fantastic. I’ve made some measurements at my highschool with a frequency generator and the results of your FFT-ROutine were very exactly.
I only had the Problem, that only signals in the area of 2kHz to 60 kHz were able to be measured right. The result for sinuswaves with lower of higher Frequency were that they also should have a peakfrequency at the area of 2 kHz to 60 kHz.
Do you know where the Problem could be? I gave pure SInuswaves with Frequency from 5 Hz to about 500 kHz as an input, but only got a peakfrequency at the kHz-area.
Thank you very much.
Hi Eli,
a FFT algorithm computes the frequencies of the samples depending on the sample frequency. By changing the TD (time per division), the max frequency of the FFT changes. Try changing the TD to higher sample frequency.
The inherent nature of FFT algorithms is that frequencies above the Nyquist frequency (sample frequency divided by two) will be displayed as a lower frequency. That is the reason that ideally a low-pass filter should be used with a filter-frequency equal to the Nyquist freq.
Hello, I tested the firmware that implements the FFT by Paulvvz and I was really impressed. In order to allow inclusion, in future versions, of the FFT calculus using open code, I used the libraries of DSP from ST and the work done by Benf and Paulvvz to also implement an FFT aplication. So, I am posting the code and firmware here. This FFT can operate with 64, 256 or 1024 points. The graph of the frequency is superimposed on the temporal graph, but using a different color. IAR 5.4 was used in the compilation. FFT_DSP_ST.rar (391 KB) Dso201_APP_FFT.rar (60.9 KB)
Hi wlacerda,
Nice work! Superimposing the FFT with yellow is very well done. This FFT really works great!
Some suggestions for improvement:
the frequency at the bottom left (nicely in yellow) always displays Hz, but can be also KHz;
the FFT amplitude varies with input amplitude. Can the value be displayed relative in dB?
And now we wait for someone to integrate this in the latest version or someone who writes a boot-laoder that let the user choose which application to boot. That would be really awesome.
Paul
I finally got to integrate the free FFT stuff into my git tree (which had the open-source 3.11 + my “infrastructure” fixes to build with gcc and IAR4/5 from common code but not much new features). For now it is in a separate fft-relocated branch at gitorious.org/dsonano/dso-firmware . I also intend to merge the later released open-source 3.13 code, which will simplify code relocation (more on that later). I have not pushed it to my master branch yet, awaiting some rebasing to make the merges cleaner.
I think I will post more on the boot-loader work in a new thread, but using it for dual-booting Benf and the free FFT version seemed like a good demonstration of it. The boot loader is work in progress and the implementation here to select BenF/FFT is just a hack. Instructions are in the zip-file.
I hope this can encourage more development on the DSO Nano!
Note: This only works with the old USB bootloader, not the new “HEX” file-based bootloader firmware. DSO-Benf-FFT-dualboot.zip (33 KB)
