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

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



What a great firts post from me - 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

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

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



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.

yes you’re right, I use 512 samples, but 1024 works without problems

[code]v1.18

• More FFT fixes
  - Better timming (less flicker)
  - Drawn over the curve (instead of merge)
  - Accurate scalling (was of by one bit)
  - All valid FFT buckets now displayed (bucket 1 is back from a vacation)
  - Peak frequency marker (chip ripoff)
  - Show FFT meters in the upper right corner:
  - Nyquist (max range)
  - Max: Predominant frequency in the sample
  - Div: Frequency range per divison
  - T1 : Frequecy at marker T1[/code]

Thanks for all the improvements!



But I want to report one bug that is also in the original firmware.

When I’m single shot triggering with a smaller time devision than 100uS I have an screen refresh problem.

It gets the trigger and switches to hold, but does not draw the data (90 percent of the times I try).

Sometimes when I just change random things in hold mode like some settings, it shows the data after all.

So it seems like a screen refresh problem.



I also have a dso nano and tested it in parallel. The dso nano had no problem displaying the triggered data.

So no problems with the data itself.



Have you experienced the same behaviour? Are you able to fix that?



Thanks in advance!

Because there’s a small fix to apply to the code to correctly refresh on SINGL at that rates. I can give the code to pmos69 if he’s interested.

Sure.



PS: I’d rather not consider this my code. My intention was to start an open-source port anyone can easily contribute to.

Most of the code comes from the original firmware and Marco’s contributions anyway.

The only way to substantially improve the current firmware and insure it keeps improving is if more people contribute.

Anyone can fork the current code on github anyway (would be nice to merge back any improvements, though).

If anyone wishes to carry on the effort, that’s also ok. I usually don’t have a lot of free time anyway.



Pedro

JackTheVendicator

It would be great to put your fix in pmos69 firmware. Now I’m usnig a DSO_Sm_JTV_V1.71 and satisfied with it, but I would like to use the new features without losing the correct operation of single-mode.