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

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 :confused:

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.

: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.