# DSO203 GCC APP - Community Edition (2.51+SmTech1.8+Fixes)

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?

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]

• [*]why so many harmonics? The mains should be a very good sine, I donâ€™t expect anything significant above 50Hz. Is this noise because of the limited resolution of the ADC? Or a â€śfeatureâ€ť of the FFT? Of because of the vertical logarithmic scale?
• [*]the rays in the spectrum are not really rays, they are rather blurred - is that a "feature" of the FFT too (e.g. because of the width of the bandpass filter?)
• [/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]