> Hi John >> >> We are building several new pulsar and spectral line personalities, and >> we >> have a weird problem with the FFT block. No matter how many channels we >> configure a block for, the last channel in each 1/8th of the spectrum is >> getting lost. For instance, if we have a 64 channel personality, >> channel >> 0-6 is fine, channel 7 is not fine, channel 8-14 is fine, 15 is not >> fine, >> etc. > > Just to ask if this is the fft_wideband_real block?
Yes, I believe it is... > > In my recent adventures into the fft library I did come across a bug > that affects fft_biplex_real_4x (and by extension fft_wideband_real) > output. > > It was in the init script for mirror_spectrum used in the > bi_real_unscr_4x block. There was a swap in latency settings for delay > blocks for the sync input (sync_delay0 and sync_delay1 specifically). > This caused some of the output channels to be swapped on output (with > the actual fft_bins affected depending on latency settings). > Unfortunately, this bug was introduced in commit 007f55c55 (in 2011) so > has been around affecting our data for a while. This is fixed in the > latest fft changes in the ska-sa repo on github. > >> You can see this by placing a sine wave into the ADC corresponding to >> bin >> 6. Bin 6 shows a healthy spike in the output FFT. Life's good. >> >> Now change the frequency of the sine wave and put it into channel 7. >> The >> line (very nearly) goes away in the output. Move the frequency again to >> channel 8, and the line pops back up as it should. >> >> This happens no matter how many channels you build, the last channel in >> each 1/8 of the band is corrupted this way. >> This is using snap blocks to read the data straight from the FFT block, >> btw, so there's no other cruft in the test. >> >> Has anyone seen this? It seems to simulate correctly from what we can >> see, which is even more mysterious. > > You can see this bug clearly in simulation using an impulse response as > input to the fft. Input a pulse of amplitude 0.5 into the second fft > input one clock cycle after the sync pulse (0s on shift input). You > should get a complex exponential with frequency 1 (f(t-delta) <=> > e^(-delta*fw)F(w)) on the output. It is easy to see channel swapping as > the output function is nice and smooth. OK. We'll try a new library version. Thanks! John > > >> We're using the casper library: >> >> [ptcs@ptcs /export/home/ptcs/scratch/guppi2/libraries/mlib_devel]$ git >> log -1 >> commit 6050c725f770f0bdb776fae107dc4fe26f7fce51 >> Merge: f50084e 0c15bf7 >> Author: Andrew Martens <and...@ska.ac.za> >> Date: Mon May 20 10:59:32 2013 +0200 >> >> Merge branch 'master' of https://github.com/ska-sa/mlib_devel >> >> Copied new bitsnap block into separate module and added it by hand >> in >> casper >> Made the change of BRAM to bram in the snapshot block in >> casper_library_scop >> >> Conflicts: >> casper_library/casper_library_misc.mdl >> casper_library/casper_library_scopes.mdl >> > Try with the latest commit for the same repo and see if that makes a > difference. > > Regards > Andrew >
