Hello all, I would REALLY appreciate if someone could help me figure out why my FFT and IFFT arent working on my Motorola chip. The chip has the 56000e core. All Im doing is, taking an array of 16 Fractionals, that represents a sine wave. Im doing an in-place FFT then inverse FFT on it and the results are COMPLETELY off of what I would expect (Id expect the same sine wave back). I am using no scaling on both operations. The actual functions used are the SDK's "dfr16RFFT" and "dfr16IFFT". I've set the functions up exactly how the documentation wants, with no luck. Help! --Shafik
FFT and IFFT problems on the Motorola 56F8323
Started by ●August 5, 2004
Reply by ●August 6, 20042004-08-06
Shafik wrote:> Hello all, > > I would REALLY appreciate if someone could help me figure out why > my FFT and IFFT arent working on my Motorola chip. The chip has the > 56000e core. > > All Im doing is, taking an array of 16 Fractionals, that represents a > sine wave. Im doing an in-place FFT then inverse FFT on it and the > results are COMPLETELY off of what I would expect (Id expect the same > sine wave back). > > I am using no scaling on both operations.If you expect to get back (almost) what you started with then the overall scaling factor for the two operations must be 1/16. Since you're using a sine wave (which can be full scale I guess) then to avoid overflow you should probably use 1/16 scaling on the FFT (divide by 2 each pass) and no scaling on the IFFT. But you should also be aware that for many signals this isn't what you really want because small signals will end up dropping off the bottom of your dynamic range (they'll get swamped in the quantisation noise). Using 1/4 (generally 1/sqrt(N)) scaling on both FFT and IFFT would be another commonly used option. For radix 2 FFT's you can achieve this by dividing by 2 on alternate passes. But full scale sinusoids will overflow during the FFT in this case. Regards -- Adrian Hey
Reply by ●August 6, 20042004-08-06
Shafik, as I read your post, you're using a "Real" FFT for the forward transform stage and a complex-output version for the inverse. That won't work. Try using the real-output inverse transform (dfr16RIFFT) and make sure it takes care of the necessary scaling (most probably that is already included), then you should get what you expect. -- Stephan M. Bernsee http://www.dspdimension.com
Reply by ●August 6, 20042004-08-06
Check that your data is aligned to power-of-2 boundaries appropriate to the FFT size. This has caught me more times than I would like to admit. Ryan
Reply by ●August 6, 20042004-08-06
Stephan M. Bernsee <spam@dspdimension.com> wrote in message news:<2ngnvrFmiluU1@uni-berlin.de>...> Shafik, > > as I read your post, you're using a "Real" FFT for the forward > transform stage and a complex-output version for the inverse. That > won't work. Try using the real-output inverse transform (dfr16RIFFT) > and make sure it takes care of the necessary scaling (most probably > that is already included), then you should get what you expect.I am actually using Motorola's built in "Real" FFT and "Real" inverse FFT. Even with just observing the output of the FFT stage, I get strange results for a simple sine wave (I would expect a single spike). I have no control over the implementation of the algorithm itself, but I would hope that Motorola doesnt have such a serious bug in their 5th version of the SDK. What's going on? --Shafik
Reply by ●August 6, 20042004-08-06
On 2004-08-06 19:46:39 +0200, shafik@u.arizona.edu (Shafik) said:> I am actually using Motorola's built in "Real" FFT and "Real" inverse > FFT. Even with just observing the output of the FFT stage, I get > strange results for a simple sine wave (I would expect a single > spike). I have no control over the implementation of the algorithm > itself, but I would hope that Motorola doesnt have such a serious bug > in their 5th version of the SDK. > > What's going on? > --ShafikYou were saying in your original post that you are using the routines "dfr16RFFT" and "dfr16IFFT". The latter is *not* the inverse real transform, the inverse real transform is "dfr16RIFFT". Either you mistyped this in your original message or in your code... -- Stephan M. Bernsee http://www.dspdimension.com
Reply by ●August 6, 20042004-08-06
Stephan M. Bernsee wrote:> "dfr16RFFT" and "dfr16IFFT". ... "dfr16RIFFT" ...?? Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●August 6, 20042004-08-06
"Ryan Mitchley" <rmitchle@removethis.worldonline.co.za> wrote in message news:<41137145$0$5465$812600b3@news.nntpaccess.com>...> Check that your data is aligned to power-of-2 boundaries appropriate to the > FFT size. > > This has caught me more times than I would like to admit. > > RyanI am in fact using the proper functions for the "real" fft: dfr16rfft and dfr16rifft. What exactly do you mean by "data alignment". Do you mean memory boundary alignment or just the size? Because I am using a 16 size input data array. Thanks --Shafik
Reply by ●August 7, 20042004-08-07
Jerry Avins <jya@ieee.org> wrote in message news:<4113de94$0$5907$61fed72c@news.rcn.com>...> Stephan M. Bernsee wrote: > > > "dfr16RFFT" and "dfr16IFFT". ... "dfr16RIFFT" ... > > ?? > > JerryHi Jerry, what's the part you don't understand? --smb
Reply by ●August 7, 20042004-08-07
Stephan M. Bernsee wrote:> Jerry Avins <jya@ieee.org> wrote in message news:<4113de94$0$5907$61fed72c@news.rcn.com>... > >>Stephan M. Bernsee wrote: >> >> >>>"dfr16RFFT" and "dfr16IFFT". ... "dfr16RIFFT" ... >> >>?? >> >>Jerry > > > Hi Jerry, > > what's the part you don't understand? > > --smbI didn't see existing differences. (Believe me: I looked long and hard.) Later, I found them, but I didn't delete my message in time. Chalk it up to old age if you like, but in reality, I seem to be somewhat dyslexic. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
