[code]v1.14
- More (clueless) FFT tweakings
Replaced the Hanning Window
Applied dumb automatic scaling to the bars (based on max frequency)
Removed “bluring”[/code]
Download: https://github.com/pmos69/dso203_gcc/zipball/master
220 ac from wall it very very dirt source ))
because of many consumers like flyback power source, gas discharge lamp, etc
…right but compared to the awful “sine” of the quad, it is almost perfect 
Patrick
Yes, but sampling it with 8 bits will get it just as awful 
[code]v1.15
- Small optimizations in some FFT operations
- Fixed FFT max frequency and scale max frequency display for time scales less than 10uS/Div[/code]
Hi Pedro
Wonder if you can look at this. I tried looking at the code, but can’t figure out where it is going wrong.
See this video that shows the GCC version in SCAN mode. Here you will see the waveform is printed in 3 distinct segments that repeat themselves.
http://youtu.be/2zUi5dcPvrQ
This is another video with the AP1_100 version in SCAN mode with buffer set to 360(smallest setting). This problem does not happen here. Sad we don’t have the sources for AP1_100
http://youtu.be/VU-VZ2kq62M
Please let me know if I there is a way I can help. Right now, I cannot figure out the whole code, so, not sure where to look. But, I am guessing SYNCHRO and PROCESS are the right places to look.
Regards
Jerson
sine wave of 220 with transformer
Hi chip,
…that means you can/will contribute to the project?
All the best,
Pedro
I’m sorry, but I have my own project.
Picture order was to compare. In 220 no loud noise.
No problem.
Do you have your source code available to the public?
no
220 ac spectrogram without second 100 Hz harmonic?
Very strange ))) just do not know what to suggest
How about your spectroscope dynamic range?
About the internal generator
It is far from perfect. At first - the signal from the DAC is not filtered. Second - the output buffer amplifier goes to a limiting on the signal levels close to GND and Vss, it is noticeable even visually, and produce harmonic components.
There are other cases were the FFT seems to behave badly
(my guess, I’m really not an expert. This FFT stuff is out of my league)
, but under those same settings, the results seem similar:
dso203_gcc:
chip firmware:
Now, chip is probably using a higher FFT sample count (1024 perhaps), so the results in his firware will be more accurate.
Besides the bugs I’m sure my code has 
I don’t understand.
Did you acquire a licence to use the original firmware source code?
I see only 2 options for the original source code licencing:
- Either it’s “© COPYRIGHT 2009 e-Design Co.,Ltd.” as included in all the source files
- Or it’s “GPL/LGPL”, as stated in the seeedstudio wiki (http://www.seeedstudio.com/wiki/DSO_Quad)
If the code is not GPL and you didn’t acquire a licence, that would be stealing.
If the code is GPL you are in breach of the GPL licence, and that would be stealing also.
Note: I’m not implying you are stealing anything.
From what I know, you can be just making a personal use of the source code and your customized firmware.
It’s not an issue.
Yes, I use 1024 values of the signal and get the 256 points of the spectrum
I do not know what kind of license is needed to open source, but I know that with this code is a bad oscilloscope
[/quote]
[/quote]
Well, not just the code: The hardware also has some big flaws.
Hello
I don’t understand the behaviour of Pedro’s FFT.
I use a 10kHz “sine” from the internal DAC, channel A with 0.5V/div, 100uS/div as an example.
[list]
Maybe this has to do with the fact that only 256 samples are used, i.e. only about 10 periods and this is not enough - does the FFT only give good results when there is an integer number of periods in the 256 samples? Could this explain why the sines have so many harmonics?
I had another problem, which looks like a bug: when moving the “navigator B”, changing between the “trigger” and the “auto/norm…” menus - but not changing anything at the settings - sometimes the FFT result change completely!!!
Two more questions:
[list]
Patrick
The number of samples influences the resolution (frequency / x scale) of the FFT.
Can’t increase the number of samples at the moment because of the increase in program size/storage needs:
- TTF coef_table - about 4KB more
- the input and output arrays - about 6KB more
I’ve replaced the Hanning window lookup table with a function to generate the relevant indexed values at request, but that still isn’t enough.
Program size is already somewhat large because GCC does not optimize the code as well as IAR - by far.
Anyway, the functions are in place for using either 256 or 1024 samples, and I can get the 1024 samples FFT running under some circunstances, but don’t think it’s relevant enough to spend more of my time with it.
Anybody can compile it with 1024 samples FFT support by changing 2 lines of code and uncommenting the needed coef_table values. The code is all there.
If someone wants a better FFT program, a dedicated FFT build can easily be made without issues, that can use 4096 samples.