Recent

Author Topic: FFT scaling (old chestnut)  (Read 2446 times)

Fred vS

  • Hero Member
  • *****
  • Posts: 3158
    • StrumPract is the musicians best friend
Re: FFT scaling (old chestnut)
« Reply #15 on: January 27, 2021, 08:01:37 pm »
« Last Edit: January 27, 2021, 08:34:39 pm by Fred vS »
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

avra

  • Hero Member
  • *****
  • Posts: 2514
    • Additional info
Re: FFT scaling (old chestnut)
« Reply #16 on: January 28, 2021, 08:32:29 am »
I think I've found out what's going on. In the time domain, I was displaying a fixed number of horizontal divisions (20) and saying that the the timing (secs per division) was the same as that reported by the 'scope. However, I was also displaying the entire buffer: 512 or 1024 values rather than the 25x12=300 (I think) values in the 'scope's display window
That's why I insisted on trying TeraTerm because according to screenshot it allows downloading data along with metadata fields SampleRate and RecLen, which would be enough to understand that downloaded buffer data and oscilloscope display divisions are a miss match.
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: FFT scaling (old chestnut)
« Reply #17 on: January 28, 2021, 09:37:52 am »
That's why I insisted on trying TeraTerm because according to screenshot it allows downloading data along with metadata fields SampleRate and RecLen, which would be enough to understand that downloaded buffer data and oscilloscope display divisions are a miss match.

All of which is already in debugging output.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: FFT scaling (old chestnut)
« Reply #18 on: January 29, 2021, 11:04:26 am »
Wrapping this up: worst of all, I had a totally and unforgivably silly mistake in the RMS function that merged the FFT's real and imaginary output, which is why I was getting the same strange output from both a local FFT implementation and the (better, but not universally-bundled) FFTW.

Fixing it so that the time domain display has an integer-number of (25-sample) divisions but the FFT always sees an integer power of 2 samples, fixing the RMS problem, and with few other changes of significance, I can get things like the attached which is the output of a pretty-but-noisy USB PSU.

For a cheap and pocketable scope I feel that's a bit better than adequate. Frequency (measuring its own calibration signal) is a bit suspect, but I can fairly easily check that against a pulse-per-second GPS signal.

Anybody who wants a copy is welcome, but I'm not sticking it onto Github yet. The issue is that the project can use dynamic linkage between the frontend (generic) and backend (device-specific) parts, and while the frontend could call the backend I was having problems with calls from the backend to frontend. The worrying thing is that it worked properly with 32-bit code (on a 64-bit Linux system with multiarch, FPC 3.0.4) but not with 64-bit code, and when I last looked at this I got bemired a long way into the runtimes and standard libraries.

MarkMLl
 
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018