Hi Danny
> 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...
The one in our library looks like this:
% Set conjugation mode.
if strcmp(conjugated, 'on'),
set_param([blk, '/alumode0'], 'const', '3');
set_param([blk, '/alumode3'], 'const', '0');
else,
set_param([blk, '/alumode0'], 'const', '0');
set_param([blk, '/alumode3'], 'const', '3');
end
So you may be right. I'll have a look tomorrow.
Thanks!
John
>
> 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<[email protected]>
>> 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
>>
>>
>>
>