Hey Jason et al. On 17 September 2012 16:31, Andrew Martens <[email protected]> wrote:
> Slipping normally happens when the sync and data paths become misaligned > leading to one being shorter, longer than the other. This would add > noise and cause frequencies to move around. > > Cheers > Andrew > This was indeed the problem -- there is a bug in the sync_gen block that doesn't properly set a comparator constant value. As a result, the sync period was 2 clocks out (= 4 channels out because of even/odd interleaving). I've fixed the sync_gen block's init script and sent a pull request to the main casper repo. I've also compiled a working model (just tested on an Oxford roach with no obvious issues) which is in the tutorials_devel repo. The boffile should be good straight out of the box, but if you're recompiling the model make sure you have the sync_gen fix from the casper library first (it is immediately available in the casper_vanilla branch of https://github.com/oxfork/mlib_devel.git . This (as opposed to the oxfork master branch) should merge into the main casper repo without issue). Hopefully that's Tutorial 3 sorted..... > > On Mon, 2012-09-17 at 10:56 -0400, Jason Castro wrote: > > Thank you all for your input. It's always nice to come into work on a > > Monday and be able to hit the ground running! I loaded Jack's latest > > tutorial 3 bof file and I got some interesting results. The spectrum > > slips along the x axis 4 channels every 800ms or so. This slipping > > event is also accompanied by about 10db of noise in the stop band of the > > signal. Please see the following plots: > > > > > ftp://ftp.cv.nrao.edu/NRAO-staff/jcastro/CASPER/Spectrometer/Tutorial_3_sliding_spectrum1.PNG > > > ftp://ftp.cv.nrao.edu/NRAO-staff/jcastro/CASPER/Spectrometer/Tutorial_3_sliding_spectrum2.PNG > > > > I'll dive into this and try to figure out what's going on, but extra > > eyes are appreciated. > > > > Thanks, > > > > Jason Castro > > NRAO > > > > > > > > On 9/17/2012 8:03 AM, Jason Manley wrote: > > > On 17 Sep 2012, at 11:45, Jack Hickish wrote: > > >> 2^27 isn't a valid sync period for tut3, which has an FFT ending in a > 10th order reorder (https://casper.berkeley.edu/memos/sync_memo_v1.pdf). > > > Good catch! This is what I get for copy-pasting that design from > another :-/ > > > > > > Tut3 has been in use in CASPER for over 3 years now and I think you're > the first one to notice! > > > > > > Jason > > > > > > > >
