Hi all.

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.

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.

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


Thanks.

John



Reply via email to