Thanks to visit codestin.com
Credit goes to github.com

Skip to content

specgram(x) should warn if x.size < 256 #6064

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
roger- opened this issue Feb 26, 2016 · 7 comments
Closed

specgram(x) should warn if x.size < 256 #6064

roger- opened this issue Feb 26, 2016 · 7 comments
Milestone

Comments

@roger-
Copy link

roger- commented Feb 26, 2016

The default NFFT size of 256 gives misleading results if x.size << 256, for example this chirp:

import numpy as np
import pylab as pyl
from scipy.signal import chirp

fs = 200
t = np.arange(0, 1, 1/fs)

signal = chirp(t, t1=1, f0=0, f1=100)

pyl.specgram(signal, Fs=fs)
pyl.show()

Gives this. Passing NFFT=32, noverlap=16 to specgram() gives this more reasonable result.

Simplest fix is probably just to warn users when their data is too small.

@tacaswell tacaswell modified the milestones: unassigned, 2.1 (next point release) Feb 27, 2016
@tacaswell
Copy link
Member

Are the results wrong or just misleading? Warnings tend to not be read by users who should read them and just annoy users who read them, but know what they are doing.

I would prefer to either raise if the length of the data is less than NFFT or add a comment to the docstring.

@roger-
Copy link
Author

roger- commented Feb 27, 2016

Well with the default parameters and a small array the spectrogram is wrong since it shows a static distribution of power.

I don't know if there's ever a case when it's useful to have an NFFT that's bigger than your data, but an exception could work too. An alternative is have an 'auto' option by default that picks better values.

@tacaswell
Copy link
Member

Thinking about this a bit more, the result is 'correct', in that there is only one window and it gives you back time point sample, just not terribly useful.

@flothesof
Copy link
Contributor

Looking at this problem, I agree with @tacaswell : the result is what the user asked the specgram function to produce.

Because when asking for
pyl.specgram(signal, Fs=fs, NFFT=64, noverlap=32, pad_to=1024) the result becomes what @roger- might have expected: an upward trending slope for frequency.
image

So the point is not that the spectrogram is wrong, rather that the default value for NFFT (which is 256) is not adapted to a case where you only have 200 points in the input signal, I would say.

Hope this clarifies the issue a bit.

Best, Florian

@roger-
Copy link
Author

roger- commented Mar 14, 2016

@flothesof: well I guess "wrong" in the sense that the default NFFT=256 is unable to produce a useful spectrogram if you have less than a certain number of points.

I think a simple check and a warning would be good in this case so it doesn't bite anyone with a misleading representation of their signal.

@dstansby
Copy link
Member

Looks like this is fixed and good to be closed!

@roger-
Copy link
Author

roger- commented Jan 28, 2017

Awesome!

@roger- roger- closed this as completed Jan 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants