Desktop Recorder

Hi Raf,

I understoud and was aware of the 2 blades.

But I still don't agree with you:
- you agree with the 2,69 Hz OK
- but this is the frequency scale and completely independant of the signal you are measuring, this is purely physics and maths
- you can set the scale either in Hz or in RPM still independent of any singal
Until now we have a signal analyser with above caracteristics.

Now when you record a signal you must ask yourself: what frequencies should, could or would I see in the spectrum and only here you must take into account the 2 blades.
So what are these frequencies with a rotor rotation speed for example 1200 rpm:
- the rotation of the rotor 1200 rpm > 20Hz
- the blade frequeny 2 times rotor 40 Hz
- as the blade frequency is not a pure sine you will have a certain number of harmonics 80, 120, 160 Hz etc.
- probably the blade frequency is modulated by the rotor frequency, in this case you will see 'side bands'. In an amplitude modulated signal you have the carrier frequeny, in your case the blades, and the modulating frequency in your case the rotor. In the frequency spectrum you will see 3 spectral lines: the carrier frequency and two side band lines with the carrier frequency plus and minus the modulating frequency.
Your case is a special one because the carrier frequency (blades) is the double of the modulating frequency (rotor) this means that the frequency of the lower side band is the same as the modulating frequency.
At the end you could find following frequencies:
- 20 Hz rotor and lower blade side band
- 40 Hz blade, 2nd rotor harmonic
- 60 Hz upper side band, 3rd rotor harmonic
- 80 Hz 2nd blade harmonic 4th rotor harmonic side band
and so on.
Now the amplitudes of the different peaks will depend on the 'purity' of the noise produced by the different elements.
- Rotor probably relatively pure
- Blades, anything but pure

So probably the main peaks should be:
40 Hz baldes
80 hz 2nd blades harmonic.

I hope all this stuff is clear enough.
The amplitude modulated frequency example is already included in the (not yet posted) test program.

Best regards.

Hi Andrew,

First of all, thank you for your support.

I have tested the last version, it works well.
Just the amplitude problem.
It is a scaling problem when using Fft.Transform2.
Because not only the DC component is double but also the frequency amplitudes are doubled. The problem is that the sample number of FFTReal after Fft.Transform2 is half of the sample number after Fft.Transform.
Is there a way to memorize the sample number after Fft Transform for the other conversions ?
Another way would be to directly scale the real and imag FFT signals according to the real data sample number. Then the other conversions are coherent.

Best regards.

klaus said:

It is a scaling problem when using Fft.Transform2.
Because not only the DC component is double but also the frequency amplitudes are doubled.

Click to expand...

I was using FFT.Transform when I saw the effect, not Transform2. I haven't tried it for Transform2. With a DC offset of 1 in the time domain I saw a DC amplitude of 2 in the frequency domain, the Sine amplitudes were 1 as expected.

There may be a scaling problem in Transform2. I'll look tomorrow but I thought I had taken that into account.

Hi Andrew,

I tested a bit more.
The problem with the DC component doubling is also present in FFT Version 1.1 with the original dll before splitting.
It seems related to the FFT algorithm, I would have expected 1 and not 2 as you. I have no explanation for that.

The scaling problem, I reported yesterday, with Transform2 came out with the following.
I transformed with Transform2 and then I used ToAmplitude and ToPhase.

For the scaling, I would suggest to scale directly FFTReal and FFTImag in the transform functions, so there will be no problem with ToAmplitude and ToPhase independent from what Transform function was used.

When I remember the spectrum analysers I used some years ago the real and imag values were scaled. I don't remember having seen the amplitude values beeing multiples of the sample number.

As now we have Transform2, the function ToAmpAndPhase is no more useful.

Attached 2 test programs
FFTdemoKC1_1_1 for FFT dll version 1.1
FFTdemoKC1_1.5 for FFT dll version 1.5

The program is not yet finished but could already be useful for.

Best regards.

klaus said:

I would have expected 1 and not 2 as you. I have no explanation for that.

Click to expand...

I wonder if it is something to do with the fact that as I noted there is no DC component in the complex conjugate part. Maybe the DC component has the complex equivalent added to it and that is why it is double the size.

For the scaling, I would suggest to scale directly FFTReal and FFTImag in the transform functions, so there will be no problem with ToAmplitude and ToPhase independent from what Transform function was used.

Click to expand...

Sounds like a good idea.

As now we have Transform2, the function ToAmpAndPhase is no more useful.

Click to expand...

I'll remove it to keep things tidy - I like tidy

Hi Raf,

I like the layout of your Tachometer.
Will the needle move according to the speed ?
Would look nice.

Best regards.

I think I've fixed the scaling. Also Inverse2 was broken, it should now work but FFTdemoKC1_5 throws exceptions when I try the IFFT as your indexers are out of range.

klaus said:

I like the layout of your Tachometer.
Will the needle move according to the speed ?
Would look nice.

Click to expand...

Hi Klaus,

Sorry, had no time to reply yet, but you know I gladly take all your advice and opinions.
No, i'm not there yet, the needle doesn't move, I really don't care so much, but many people would love that. For now, I'm concentrating on function over esthetics, lack of time, you know. Since today, the app looks like this, added this little autoscaling graph and a list with the 5 strongest frequencies to give some more info to the user. I hope you like it, I'm just a hobbyist.

BTW, this is a real measurement of one of my R/C helis, recorded with the app, and calculated by the app on my HTC. It works, and fast even, thanks to you gentlemen
Oh, and the desktop version works just as well, a lot faster even of course, see this pic:

Hi Andrew,
Here is the last version of the demo program.
It can work:
- with either Transform/Inverse with variable Transform = 0
- with Transform2/Inverse2. with variable Transform = 2

The help in the program is a minimal one, if there is an interest I could write a more detailed one.

Comments on the library.
- scaling is half the original amplitudes.
- as now the scaling is directly done in the Transform functions there is no need anymore to have a scaling factor in the ToAmplitude, ToReal and ToImaginary functions.
- the DC offset amplitude is still the double of the sine's amplitudes, I have not yet looked to find out why this happens.

Best regards.

EDIT: removed the file. there is a new one in post #80.

klaus said:

scaling is half the original amplitudes.

Click to expand...

I'm away for the weekend with just a netbook. I noticed this, but I didn't have time to investigate. I thought that I had merely moved the scaling from Inverse to Transform. The present scaling seems to to be what is needed for the Inverse to return the original time series. I'll look again when I'm back on Monday afternoon.

as now the scaling is directly done in the Transform functions there is no need anymore to have a scaling factor

Click to expand...

I thought that I would leave it in in case it was needed as it is faster to do it there than in a loop in Basic4ppc.

the DC offset amplitude is still the double of the sine's amplitudes, I have not yet looked to find out why this happens.

Click to expand...

As the algorithm round-trips OK I assume that it is a part of how the algorithm works but it would be interesting to know why.

Hi Raf,

How do you like the attached sample program ?
Tachometer with moving needle.

Did you have a look at post #61

Best regards.

Hi Andrew,

If we would like to maintain a scaling factor I would suggest to put it into the Transform,Transform2, Inverse and Inverse2 functions. That way the FFT real, imaginary and amplutude samples are coherent with the same relative ampltude.

Best regards.

Hi Klaus,

Thanks a lot for the moving needle !
It's a sure thing that I'm going to incorporate that code into the tachometer, it looks way to nice to leave it unused. With a little help from Photoshop, I'll even make a copy of the original needle and the tachometer without the needle. I had no time to do it myself, but i would never have programmed it as fast as you did anyway. And another name for my credit list, I guess.

I indeed looked to your post 61, very hard even, and I keep being puzzled by one thing. Somewhere I must make an error in my thinking, but I fail to see where exactly. The math and physics are different things, but allow me to explain anyway what I am thinking:
In the given circumstances, our subsequent results are indeed 2,69 Hz apart. I follow you until there. Meaning the values can be like 0 - 2,69 - 5,38 - 8,07 Hertz and so on, raising until the 2048th value. Meaning the frequencie values in RPM for an object making one sound during each rotation will be 0 - 161,4 - 322,8 - 484,2 RPM and so on. Indeed a 160 RPM interval, with an accuracy of +/- 80 RPM. All good until here.
With my "object", making 2 sounds per rotation, I have to divide by a factor 2, otherwise the result would be the double, and faulty. So I get possible results like 0 - 80,7 - 161,4 - 242,1 - real RPMs of the shaft, which I am NOT measuring, BTW. Meaning I can get possible (correct) results with an interval of only about 80 RPM, which makes me think my accuracy is better, like +/- 40 RPM ? I neglect any sounds/frequencies from the shaft, as the blades produce by far the loudest sound mostly. I did the same mental exercise with a rotorhead carrying 3, 4 or even 5 blades, and came to the same conclusion. Sorry for being so persistent this time, I don't mean to think I am right, but am annoyed by the fact that I fail to understand this subject better.

I was thinking this is a bit like measuring, let's say, a distance of 100 meters with any device that is accurate within 10 centimeters at precisely 100 meters. Wouldn't the accuracy not be like 5 centimeters at a distance of 50 meters ? Supposing there is no fixed error, and only a linear error of course. Like the distorsion you get under temperature and force influences on a band shaped indexed rollmeter.

Hi Raf,

I'm shure that we will agree each other now, we were looking at the subject from different points of view!

When I posted my figures about accuracy I was reasoning in a general case like for a frequency analyser where the frequency interval with your figures is 2.69 Hz or 160 RPM and the accuracy +/- 80 RPM. That's the accuracy of the analyser.

But you went already some steps further in scaling your frequency analyser for your special case where you have the facor of 2 for the blades. And with this scaling your are right that the accuracy is +/- 40 RPM. But with this scaling the reasoning for other frequencies becomes a little bit trickier because you need, once more, to take into account the factor of 2.
But anyway as your system is a dedicated one leave it as it is.

I'm glad that you like the moving needle.

Best regards and sorry for having made you doing some brainstorming.

I'm back and version 1.7 has the scaling parameter for the amplitude and phase conversion and reconversion removed as Klaus doesn't seem to like them.

@Klaus - some pedantic quibbling.

"Vesrion" typo in the Form text.

Sines are boring, why not stick a Cosine or two in so we get some real elements?

In Config 20 periods produce a frequency of 10! Surely a period should corresond to a be a full 360deg cycle. Similarly modulation period

In Config "Sinus definition" probably "Sine definitions". According to Chambers dictionary Sinus in English is "an air filled cavity in the bones of the skull". I can find no definition relevant to sinusoidal periodic phenomena.

Hi Andrew,

some pedantic quibbling.

Click to expand...

I don't find it pedantic nor quibbling ! That's the way to get better programs.

Sines are boring, why not stick a Cosine or two in so we get some real elements?

Click to expand...

I replaced 5 sines by 3 cosines and added for n sines in the Config a phase parameter that allows sines with any phase (90° for a cosine).

In Config 20 periods produce a frequency of 10! Surely a period ...

Click to expand...

Fixed, it happened only when using Transform=0

In Config "Sinus definition" probably "Sine definitions".

Click to expand...

Fixed, that's the problem when writing in other language. In my current language, french, sine<>sinus. So it didn't look strange to me.

Wouldn't you set the scaling factor in the Transform functions to get the original amplitudes of the sines?

Best regards.

EDIT: removed the file. there is a new one in post #80.

klaus said:

Wouldn't you set the scaling factor in the Transform functions to get the original amplitudes of the sines?

Click to expand...

I thought that I had eliminated all extenal scaling but retained the internal scaling so that a Transform followed by a ToAmplitude/Phase then a ToReal/Imaginary then an Inverse returned (with reasonable accuracy) the original time series. Does it not?

What I meant with scaling to get the original amplitudes is the following:
A sine in the time domain with, a given apmlitude, when transformed into the frequency domain should still have the same amplitude as in the time domain.
Actually the amplitudes of the sines in the frequency domain are half of the amplitdes in the time domain.

Best regards.

klaus said:

the amplitudes of the sines in the frequency domain are half of the amplitdes in the time domain.

Click to expand...

That's why I originally put the scaling in ToAmplitude. However version 1.8 now has it built into the transforms and inverses.

I've only just found the graph cursor function in the demo by accident. Nice touch but it needs documenting that it's there!

I'm assuming that the library is probably final now. If you post a final demo version I'll package it all up and post it, probably reverting the version to 1.0. If you want to write a brief (or otherwise) description of how to drive the demo and what it is doing and post it as a text file I can take that and add it as a separate topic in the help file.

EDIT:- I think the amplitudes quoted in the demo help need checking. For example "1 Sine" is stated as amplitude 1 in the help but measures 0.8 in the FFT.

Here is tha last version of the demo program with a small Word help file.

I've only just found the graph cursor function in the demo by accident. Nice touch but it needs documenting that it's there!

Click to expand...

I hoped you would discover it . Is now documented.


I reset also the program's number to 1.0 .

I think the amplitudes quoted in the demo help need checking.

Click to expand...

I had noticed this too, is fixed.

Best regards.