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

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.

:confused:

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]

  • [*]when I vary the amplitude of the sine, the spectrum changes completely. For example, at amplitudes of about 1.7V, the highest peak is at 20kHz, not 10kHz (and it is more then 2 div higher than the 10kHz)
  • [*]with an amplitude of 2.1V, the picture changes: now the highest peak is at 10kHz and 2 div higher than the 20kHz
  • [/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]

  • [*]if the number of samples is the problem, why not make an FFT with 4096 sample? Why is it more complicated than with 256?
  • [*]what is the vertical scale?
  • [/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.

    [code]v1.16

    • Replaced Hanning window lookup table with function (memory optimization)[/code]

    https://github.com/pmos69/dso203_gcc/zipball/master

    Is there a hex file to download or do we need to compile ourselves?

    The needed hex (APP_G251.hex) is in the Bin directiry



    What a great firts post from me :wink: - but if it helps!

    [code]v1.17

    • Complete FFT re-implementation: (still has bugs)
      - FFT assembly routines replaced with “no nonsense” integer C code
      - All calculations made in-place (half the memory used)
      - Now using 512 samples (256 buckets)
      - FFT range boundary painted in blue
    • Project cleanup (code size reduction)[/code]

    This time it looks and operates fine.

    I hope so. My head hurts from all this math :slight_smile:

    At least it’s better, and still has room for further optimizations.

    Just wanted to release it once I got it working.

    Yes, so much better.

    image for comparison

    :slight_smile:

    Wow, seems like I got the scaling right also.

    Thanks.

    Great pmos69 !

    and where you hid the constant component of the signal? in DC mode

    The constant component of the signal?

    Yes. on the spectrum

    Still not exactly sure what you mean. Let’s see if I understand :slight_smile:



    I’m hiding the first fft bucket which should have the representation of the DC and close to DC components of the signal.

    The actual “virtual zero” of the samples is not relevant for the FFT calculation, and I’m actually using all positive (8-bit) samples from the ADC bitshfited (<<3) into a 16bit signed int, which is what is used in the FFT input/output array. (further bitshifting is done in the fft code to avoid overflows).



    I also got code working for doing the fft calculations using 8-bit, but the signal-to-noise ratio seems to be too low for good results, although it works. Can’t get a decent scaling working with that.

    I use 16-bit signed in/out

    I thought you did. (From my tests, 8 bit calculations are simply not enough. - I got it working to try to save further memory, but it’s not good enough, so I’ll stick to 16 bits also).



    What I don’t understand is when you say:


    If you use 1024 samples, you can get 512 frequency buckets to display (one half of the mirror output).

    How come you only get 256?

    512 real samples can give you 256 FFT frequency buckets…



    I actually had the scaling wrong by one bit. I’ll release a fixed version soon.