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
>>
>>
>>
>



Reply via email to