v1.9 released:
Enjoy,
Pedro
[code]v1.10
- Improved(/fixed) FFT calculation and display.[/code]
Pedro
wow!
thank you, Pedro!
No problem.
Let’s see if more people can contribute.
It’s easier now. The environment is very easy to get up and running.
Pedro
PS: Meanwhile…
[code]v1.11
- Corrections in TH and TL readings:
TH calculations for channels B, C and D were wrong.
TH and TL readings were swapped for all channels. - Fixed Frequency unit for K and M
was: Hz - KC - MC
now: Hz - KHz - MHz[/code]
Very good work!!! :o :o :o
I’ve a question: which is the fft frequency scale?
I’ve found only a little bug, in the trigger level label visualization, when i go in manual and return to automatic level the field remain dirty (a part of V1 text).
Thanks Marco. Glad you could check it out. 
I noticed the trigger level display bug. Will have to check it…
The frequency scale on the FFT is actually dependent on the x scale sample time.
It’s something like:
Nyquist_freq should be = (1.000.000.000.000 / _T_Scale) / 2
(_T_Scale is in nS)
The whole FFT graph (256 lines) x_scale should cover from 0 to the Nyquist_freq.
so each line in the FFT should be = Nyquist_freq / 256
… I have a build with that value and the top frequency from the FFT displayed.
I’ll just fix the trigger level thing and release it…
here’s the code for those calculations:
[code]
NFreq = (1000000000 / (_T_Scale)) / 2;
NFreq *= 1000;
Int2Str(NumStr, NFreq, F_UNIT, 4, UNSIGN);
Print_Str( 248, 0, 0x0005, PRN, NumStr);
PeakFreq = 0;
imax = 0;
for (i=0; i < (256); i++) {
if (PeakFreq < arrout[i]) {
PeakFreq= arrout[i] ;
imax = i;
}
}
Int2Str(NumStr, ((NFreq / 256) * imax), F_UNIT, 4, UNSIGN);
Print_Str( 92, 0, 0x0005, PRN, NumStr);<e>[/code]</e></CODE></r>[code]v1.12
- Display of FFT data (over the buffer position box)
on the left: Peak frequency detected in the FFT
on the right: The max frequency of the FFT graph scale - Fixed trigger level display (Thanks Marco)[/code]
Hello Pedro
I am trying to load your APP HEX file into my dso. But, it comes back with either .err or .not
I am able to load Marcos V1.8 and also the new AP1_P100.Hex but not your HEX or BIN. What could be wrong?
My FPGA is 2.60 (unable to bring it down to 2.51 even after successful downloading)
SYS chip v1.51
I have already put apps in APP1 and APP3 slots. Does that matter??
Regards
Jerson
Well, I don’t know, really.
I’m actually using FPGA 2.61 (will update the readme file with that info) and have no problems.
Using the “official” SYS1.51.
Are you getting the HEX from the zip file or from github?
No, having other apps in the slots previouslly doesn’t matter.
Pedro
Hi Pedro
I took the files from the Github latest release 1.12
Always comes back with ERR or NOT
Regards
Try extracting from the zip (on the first post).
Github has the nasty habit of messing up binary files…
Hi Pedro
Thank you very much. That did the trick. It works now. Surprising since I downloaded even the ZIP from Github
Thanks again
Regards
Jerson
Yes, I think it’s git that does some sort of conversion right when I upload things.
Would fix it, but my git knowledge is very limited 
First impressions. FFT seems to lose the ending frequency when going >= 5uS. I love the 2nd button press choosing the trigger levels. Very handy
Regards
Jerson
Yes, the FFT is a bit “crude”, but I just wanted to get a working version running. The thing with the ending frequency seems like a question of datatype or datatype conversion, but I didn’t really look into it.
I’ve also used the FFT with 1024 points instead of 256 and it runs without issues and is much more precise, but displaying that involves a bit more work, scaling the output to the display window (and I didn’t do that.)
The trigger level presets is all Marco’s work
PS: oh, and I think I fixed the github binary files corruption thing…
[code]v1.13
- Corrections in the FFT calculations
(was making a mess, as usual)[/code]
Let me take this opportunity and give a big thanks to Pedro, Marco and others that have incrementally contributed to improving the s/w. I think this was the original intend of this product, and gracious individuals have taken upon themselves the task to deliver the s/w. BRAVO!
Yes, Marco and then Pedro did a great job, thank you very much. And the work of Pedro allows each of us to compile the firmware using a free compiler.
The integration of FFT is very nice but I don’t understand what it measures exactly. Look at the following example (230V mains with 10x probe):
[attachment=0]IMAG000.jpg[/attachment]
Two things irritate me:
[list]
Patrick
I would say the calculations are incorrect…
…or not.
I wouldn’t say an 8bit capture of a sine with about 30 samples per cycle like you show is a very good representation of a sine wave.
It’s a very poor one actually, and it would be strange to not get a lot of harmonics.
If you increase the time resolution (samples per cycle) you’ll start getting better results.
…but please remember - this is a 256 samples FFT.
It’s usefulness is limited.
Had some problems reverting back to the 1024 points FFT I had first implemented, and will probably not be trying to get it running any time soon.
If someone want’s to have a go at it… (all the FFT related code in the source is delimited with “// FFT” comments, and is actually very few lines of code)
[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