On Tuesday 08 August 2017 21:02:09 Fred van Stappen wrote:
> In your fft example:
>
I don't think I can explain the whole discrete-Fourier-transform (DFT) thing
because my English and my mathematical skills are limited, maybe read the
links I provided.
> A array is assigned to fftcomp:
> fftcomp.inpreal:= ar1;
>
The DFT transforms a series of complex values in time domain to a series of
complex values in frequency domain. The imaginary values of the input
normally are zero so "inpreal" accepts a series of real values.
> After this fftcomp.outreal produces a new array of float:
> frequdisp.traces[0].ydata:= fftcomp.outreal;
>
"outcomplex" returns the complex frequency values, "outreal" returns the
magnitude of the frequency values.
> Also fftcomp.windowfunc is defined.
> But what is the usage of windowfunc ?
>
The DFT "assumes" that the input sequence is repetitive -> if the input period
time is not exactly a multiple of the sample window there will be errors, see
attachment. A window function which weights samples in the middle of the
sequence more than at the ends can improve the situation.
https://en.wikipedia.org/wiki/Window_function
> Here are the 3 and 4 that I am missing.
>
> What appends to the original ar1, what did the fftcomp to any of the data ?
> I suppose that windowfunc has to do with it, but I do not understand what
> he does.
>
The input data is untouched.
> On fft demo, on the right side, frequdisp, that uses
> frequdisp.traces[0].ydata, (the new fft array) what does it show ?
>
The right half of DFT frequency array is the mirror image with inverted
imaginary part of the left half so "outreal" only returns length(inpreal)/2 +
1 items. The first value is the DC-value, the last is the level of sampling
frequency / 2.
> Does fftcomp deals with channels (or must the array be split before)?
>
They must be split.
> By the way, one more time, I am ***very*** impressed.
>
> Other thing.
>
> I have found all the parts to make run my new toy: a RPi3B.
>
> Last nigth, installation offline of:
>
> 2017-06-21-raspbian-jessie.zip:
> --> micro-sd --> Rpi --> in one shot, out of the box.
>
> fpc-3.0.2.arm-linux-eabihf-raspberry.tar:
> --> install.sh --> in one shot, out of the box.
>
> mseide_arm_linux_eabihf_4_4_2.tar.gz:
> --> in one shot, out of the box.
> (Only a symlink must be added: libX11.so to libX11.so.6).
>
The libx11-devel package is needed.
> mseide-msegui-master-f41xxx.tar.gz:
> --> compile existing msegui projects --> ok --> run --> **OK**
>
> **WOW**
>
:-)
And nonetheless there is no interest in Rpi community for MSEide+MSEgui.
A cross compiling and remote debugging environment for RaspberryPi with MSEide
is here:
https://sourceforge.net/projects/mseide-msegui/files/fpcrossarm/
Martin
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
