Hi John
I have had similar problems in the past. At the time I switched back to
our 'stable' 11.x library and used that to compile.
We now think it's because our cmult_dsp48 broke during an overly
adventurous git merge:
https://github.com/oxfork/mlib_devel/commit/b8279fe777ce2aefa6111986092cc3cb3e8913f1
But we assumed this was confined to Oxfork. MIght be worth a look though...
Cheers
Danny
John Ford wrote:
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
