Re: [casper] Problem with Tutorial 3

[Jason Castro]

Sorry, I'm clocking the ADC at 800Mhz and therefore the FPGA at 200Mhz.  
So the glitch occurs on every 2^21 clock cycles of the FPGA.


Jason Castro
NRAO


On 9/17/2012 2:47 PM, Jason Castro wrote:
Are we sick of Tutorial 3 yet???  I discovered yet another 25dB glitch 
on a longer time scale. Again, I'm clocking the FPGA at 800Mhz.  The 
glitch occurs about every 63 seconds or 2^23 clock cycles.  Here's 
another link to a plot:


ftp://ftp.cv.nrao.edu/NRAO-staff/jcastro/CASPER/Spectrometer/Tutorial_3_glitching_60sec.PNG

Ideas???  This is turning into quite the learning experience!

Jason Castro

On 9/17/2012 1:03 PM, Jack Hickish wrote:

Hey Jason et al.

On 17 September 2012 16:31, Andrew Martens > 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
>
>

Re: [casper] Problem with Tutorial 3

[Jason Castro]

Are we sick of Tutorial 3 yet???  I discovered yet another 25dB glitch 
on a longer time scale.  Again, I'm clocking the FPGA at 800Mhz.  The 
glitch occurs about every 63 seconds or 2^23 clock cycles.  Here's 
another link to a plot:


ftp://ftp.cv.nrao.edu/NRAO-staff/jcastro/CASPER/Spectrometer/Tutorial_3_glitching_60sec.PNG

Ideas???  This is turning into quite the learning experience!

Jason Castro

On 9/17/2012 1:03 PM, Jack Hickish wrote:

Hey Jason et al.

On 17 September 2012 16:31, Andrew Martens > 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
>
>

Re: [casper] Problem with Tutorial 3

[Jack Hickish]

Hey Jason et al.

On 17 September 2012 16:31, Andrew Martens  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
> >
> >
>
>
>
>

Re: [casper] Problem with Tutorial 3

[Andrew Martens]

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

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

Re: [casper] Problem with Tutorial 3

[Jack Hickish]

Ha, thats my kind of progress. 800ms is about the sync rate I put in @
800MHz ADC clock. I just used the ready-made sync_gen block, but I'll see
if I did something stupid.

On 17 September 2012 15:56, 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
>>
>
>

Re: [casper] Problem with Tutorial 3

[Jason Castro]

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

Re: [casper] Problem with Tutorial 3

[Jason Manley]

On 17 Sep 2012, at 12:23, Danny Price wrote:
> On the topic of sync generators, I often don't bother making a periodic 
> pulse, I just set-it-and-forget-it with a single pulse,   along with some 
> arm/pps logic to sync up boards. 
> 
> Are there any strong arguments against this somewhat lazy tactic?

I think it's ok, as long as you're not using lossy links between boards. In the 
early PAPER correlators, for example, there were XAUI links between the F and X 
engines that would (on occasion), drop a data word. By propagating the sync 
pulse, the X-engines could realign themselves with the datastream periodically.

If you're on one local board then I don't think it matters much. 

It's sometimes nice to get a bit of visual feedback by placing the sync pulse 
out to an LED as a heartbeat signal to show that the board's clock is alive and 
locked. When you've got lots of boards in the rack, over time it's then easy to 
see which lights aren't blinking in sync.

Jason

Re: [casper] Problem with Tutorial 3

[Jack Hickish]

I've just pushed a fix (and boffile) to the tutorials-devel git repo

On 17 September 2012 13:03, 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

Re: [casper] Problem with Tutorial 3

[Jason Manley]

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

Re: [casper] Problem with Tutorial 3

[Danny Price]

Hi all

On the topic of sync generators, I often don't bother making a periodic 
pulse, I just set-it-and-forget-it with a single pulse, along with some 
arm/pps logic to sync up boards.


Are there any strong arguments against this somewhat lazy tactic?

Cheers
Danny


On 17/09/2012 10:45, Jack Hickish wrote:

Hi All,

On 17 September 2012 09:34, Jason Manley > wrote:


It does seem odd that this happens every X accumulations. That
almost sounds like a problem with the readout software. There's
nothing I can think of in the design that changes on those
timescales, unless there is a beat frequency between the onboard
sync generator (2^27 clock cycles) and the accumulation dump time
(~1second?).


The sync doesn't (seem to) need to be related to the accumulation 
length in this model. However, 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). Could this be 
the problem? My windows calculator reckons that means there's a sync 
every ~1.3 accumulations (accumulating over 100,000) spectra, so most 
accumulations will have a bit of dodgy data in them.
If this is the problem, accumulating for fewer spectra should make the 
rogue spikes appear much less frequently, and changing the sync period 
to (e.g.) 2^27 * 10 clocks should fix things all together.



In this case, you could check the acc_ctrl logic. What happens to
your "hump period" if you change the accumulation period?

It should be noted that tutorial 3 actually requantises to 6 bits
after the FFT. But as Paul notes, with ~1 second accumulations,
this should produce consistent results with noisy inputs and
correctly configured digital gains because over that time,
everything should average out. It will limit your instantaneous
dynamic range though.

Perhaps you could recompile without the requantiser and see if you
aren't happier with the results. If you're interested in high
dynamic ranges, consider something like the attached spectrometer
model, which has no requantisation and 64 bit accumulators. It's a
reference design we use internally at SKA-SA for RFI monitoring
with a poor PFB (2 tap, ran out of BRAM) but reasonably high
frequency resolution (16K) over 900MHz. Successfully compiled
today against SKA-sa/mlib_devel.git commit
d03afe54f0b0b949e14f4aef14b92e6413eacb88. You can get the software
to pull/plot/store the data off this model here:
https://github.com/ska-sa/ratty1

Jason



On 17 Sep 2012, at 06:46, Paul Herselman wrote:

> Hi Jason and Dan,
>
> This is really an interesting phenomenon that you picked up.
From the two spectra it appears as though the 'interference' may
be present over the entire frequency range, but obviously
overshadowed by the input signal. Does the level of interference
change with input power changes? Can you try and investigate if it
is present across all frequencies, e.g. by doing cross-correlations?
>
> Furthermore I'd be interested to know what will cause the
interference to be there only every 6th or 7th accumulation if the
source was quantization errors? Would you not expect to see it
there all of the time, or at least over an accumulation length of
100,000?
>
> Paul Herselman
> System analyst
>
> SKA South Africa
> Pinelands, Cape Town
>
> Contact Details:
> t.  021 506 7353
> f.  021 506 7375
> c. 083 415 5143
>
>
>
> On 14 September 2012 23:21, Dan Werthimer mailto:d...@ssl.berkeley.edu>> wrote:
>
> hi jason,
>
> do you care about signals that are -80 dB down?
> these spurs are likely the effects of finite precision arithmetic.
> to get suppression beyond 80 dB, you'll need to add more bits
> to the coefficients and data paths, and/or be careful about
scaling, rounding
> and the signal levels at various points in your design.
>
> here's an interesting paper on the number of bits needed for
coefficients and data path
> in FFT and PFB:
>
>

ftp://data.prao.ru:8021/Astro_archive/USERS/sam/My_doc/Radioastron/Tituls_add_note/RT/LOFAR/DELTA_MITIN/polyphasequant.pdf
>
> best wishes,
>
> dan
>
> On Fri, Sep 14, 2012 at 10:35 AM, Jason Castro mailto:jcas...@nrao.edu>> wrote:
> I'm trying to get a spectrometer working based on Tutorial 3 and
I'm running to some problems.  The signal I'm measuring has a
bandwidth of about 300 Mhz and I'm clocking my ADC at 800 Mhz.
 When I plot my spectrum with the y axis on a log scale and I
notice there are "humps" with an amplitude of about 20db that
appear and disappear periodically in what should be the stop band
of my signal.  It should be flat in the stop band.  Please see:
>
>

ftp://ftp.cv.nrao.edu/NRAO-staff/jcast

Re: [casper] Problem with Tutorial 3

[Jack Hickish]

Hi All,

On 17 September 2012 09:34, Jason Manley  wrote:

> It does seem odd that this happens every X accumulations. That almost
> sounds like a problem with the readout software. There's nothing I can
> think of in the design that changes on those timescales, unless there is a
> beat frequency between the onboard sync generator (2^27 clock cycles) and
> the accumulation dump time (~1second?).


The sync doesn't (seem to) need to be related to the accumulation length in
this model. However, 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). Could this be the
problem? My windows calculator reckons that means there's a sync every ~1.3
accumulations (accumulating over 100,000) spectra, so most accumulations
will have a bit of dodgy data in them.
If this is the problem, accumulating for fewer spectra should make the
rogue spikes appear much less frequently, and changing the sync period to
(e.g.) 2^27 * 10 clocks should fix things all together.




> In this case, you could check the acc_ctrl logic. What happens to your
> "hump period" if you change the accumulation period?
>
> It should be noted that tutorial 3 actually requantises to 6 bits after
> the FFT. But as Paul notes, with ~1 second accumulations, this should
> produce consistent results with noisy inputs and correctly configured
> digital gains because over that time, everything should average out. It
> will limit your instantaneous dynamic range though.
>
> Perhaps you could recompile without the requantiser and see if you aren't
> happier with the results. If you're interested in high dynamic ranges,
> consider something like the attached spectrometer model, which has no
> requantisation and 64 bit accumulators. It's a reference design we use
> internally at SKA-SA for RFI monitoring with a poor PFB (2 tap, ran out of
> BRAM) but reasonably high frequency resolution (16K) over 900MHz.
> Successfully compiled today against SKA-sa/mlib_devel.git commit
> d03afe54f0b0b949e14f4aef14b92e6413eacb88. You can get the software to
> pull/plot/store the data off this model here:
> https://github.com/ska-sa/ratty1
>
> Jason
>
>
>
> On 17 Sep 2012, at 06:46, Paul Herselman wrote:
>
> > Hi Jason and Dan,
> >
> > This is really an interesting phenomenon that you picked up. From the
> two spectra it appears as though the 'interference' may be present over the
> entire frequency range, but obviously overshadowed by the input signal.
> Does the level of interference change with input power changes? Can you try
> and investigate if it is present across all frequencies, e.g. by doing
> cross-correlations?
> >
> > Furthermore I'd be interested to know what will cause the interference
> to be there only every 6th or 7th accumulation if the source was
> quantization errors? Would you not expect to see it there all of the time,
> or at least over an accumulation length of 100,000?
> >
> > Paul Herselman
> > System analyst
> >
> > SKA South Africa
> > Pinelands, Cape Town
> >
> > Contact Details:
> > t.  021 506 7353
> > f.  021 506 7375
> > c. 083 415 5143
> >
> >
> >
> > On 14 September 2012 23:21, Dan Werthimer  wrote:
> >
> > hi jason,
> >
> > do you care about signals that are -80 dB down?
> > these spurs are likely the effects of finite precision arithmetic.
> > to get suppression beyond 80 dB, you'll need to add more bits
> > to the coefficients and data paths, and/or be careful about scaling,
> rounding
> > and the signal levels at various points in your design.
> >
> > here's an interesting paper on the number of bits needed for
> coefficients and data path
> > in FFT and PFB:
> >
> >
> ftp://data.prao.ru:8021/Astro_archive/USERS/sam/My_doc/Radioastron/Tituls_add_note/RT/LOFAR/DELTA_MITIN/polyphasequant.pdf
> >
> > best wishes,
> >
> > dan
> >
> > On Fri, Sep 14, 2012 at 10:35 AM, Jason Castro  wrote:
> > I'm trying to get a spectrometer working based on Tutorial 3 and I'm
> running to some problems.  The signal I'm measuring has a bandwidth of
> about 300 Mhz and I'm clocking my ADC at 800 Mhz.  When I plot my spectrum
> with the y axis on a log scale and I notice there are "humps" with an
> amplitude of about 20db that appear and disappear periodically in what
> should be the stop band of my signal.  It should be flat in the stop band.
>  Please see:
> >
> >
> ftp://ftp.cv.nrao.edu/NRAO-staff/jcastro/CASPER/Spectrometer/Humps_in_the_stop_band.PNG
> >
> ftp://ftp.cv.nrao.edu/NRAO-staff/jcastro/CASPER/Spectrometer/No_Humps_in_the_stop_band.PNG
> >
> > These humps are not present when the same signal is measured on a
> spectrum analyzer, so I'm fairly certain that these humps are not real and
> are produced inside the Roach spectrometer.  The occurrence of these humps
> is very predictable.  With acc_len set to 10 the humps occur with the
> pattern of every 6th, 7th, 6th, 7th, 6th, 7th, 6th, 7th, 7th acc samples.
>  To me, something this predictable points to a proble

Re: [casper] Problem with Tutorial 3

[Paul Herselman]

Hi Jason and Dan,

This is really an interesting phenomenon that you picked up. From the two
spectra it appears as though the 'interference' may be present over the
entire frequency range, but obviously overshadowed by the input signal.
Does the level of interference change with input power changes? Can you try
and investigate if it is present across all frequencies, e.g. by doing
cross-correlations?

Furthermore I'd be interested to know what will cause the interference to
be there only every 6th or 7th accumulation if the source was quantization
errors? Would you not expect to see it there all of the time, or at least
over an accumulation length of 100,000?

*Paul Herselman*
*System analyst*

SKA South Africa
Pinelands, Cape Town

*Contact Details:*
t.  021 506 7353
f.  021 506 7375
c. 083 415 5143



On 14 September 2012 23:21, Dan Werthimer  wrote:

>
> hi jason,
>
> do you care about signals that are -80 dB down?
> these spurs are likely the effects of finite precision arithmetic.
> to get suppression beyond 80 dB, you'll need to add more bits
> to the coefficients and data paths, and/or be careful about scaling,
> rounding
> and the signal levels at various points in your design.
>
> here's an interesting paper on the number of bits needed for coefficients
> and data path
> in FFT and PFB:
>
>
> ftp://data.prao.ru:8021/Astro_archive/USERS/sam/My_doc/Radioastron/Tituls_add_note/RT/LOFAR/DELTA_MITIN/polyphasequant.pdf
>
> best wishes,
>
> dan
>
> On Fri, Sep 14, 2012 at 10:35 AM, Jason Castro  wrote:
>
>> I'm trying to get a spectrometer working based on Tutorial 3 and I'm
>> running to some problems.  The signal I'm measuring has a bandwidth of
>> about 300 Mhz and I'm clocking my ADC at 800 Mhz.  When I plot my spectrum
>> with the y axis on a log scale and I notice there are "humps" with an
>> amplitude of about 20db that appear and disappear periodically in what
>> should be the stop band of my signal.  It should be flat in the stop band.
>>  Please see:
>>
>> ftp://ftp.cv.nrao.edu/NRAO-**staff/jcastro/CASPER/**
>> Spectrometer/Humps_in_the_**stop_band.PNG
>> ftp://ftp.cv.nrao.edu/NRAO-**staff/jcastro/CASPER/**
>> Spectrometer/No_Humps_in_the_**stop_band.PNG
>>
>> These humps are not present when the same signal is measured on a
>> spectrum analyzer, so I'm fairly certain that these humps are not real and
>> are produced inside the Roach spectrometer.  The occurrence of these humps
>> is very predictable.  With acc_len set to 10 the humps occur with the
>> pattern of every 6th, 7th, 6th, 7th, 6th, 7th, 6th, 7th, 7th acc samples.
>>  To me, something this predictable points to a problem in the digital
>> design.  A plot of the time between humps can be seen here:
>>
>> ftp://ftp.cv.nrao.edu/NRAO-**staff/jcastro/CASPER/**
>> Spectrometer/Humps%20in%20the%**20stop%20band%20time%**
>> 20between%20humps.PNG
>>
>> Has anyone else seen this behavior?  Any ideas of what it is and how to
>> get rid of it???
>>
>> Thanks,
>>
>> Jason Castro
>> NRAO
>>
>>
>

Re: [casper] Problem with Tutorial 3

[Dan Werthimer]

hi jason,

do you care about signals that are -80 dB down?
these spurs are likely the effects of finite precision arithmetic.
to get suppression beyond 80 dB, you'll need to add more bits
to the coefficients and data paths, and/or be careful about scaling,
rounding
and the signal levels at various points in your design.

here's an interesting paper on the number of bits needed for coefficients
and data path
in FFT and PFB:

ftp://data.prao.ru:8021/Astro_archive/USERS/sam/My_doc/Radioastron/Tituls_add_note/RT/LOFAR/DELTA_MITIN/polyphasequant.pdf

best wishes,

dan

On Fri, Sep 14, 2012 at 10:35 AM, Jason Castro  wrote:

> I'm trying to get a spectrometer working based on Tutorial 3 and I'm
> running to some problems.  The signal I'm measuring has a bandwidth of
> about 300 Mhz and I'm clocking my ADC at 800 Mhz.  When I plot my spectrum
> with the y axis on a log scale and I notice there are "humps" with an
> amplitude of about 20db that appear and disappear periodically in what
> should be the stop band of my signal.  It should be flat in the stop band.
>  Please see:
>
> ftp://ftp.cv.nrao.edu/NRAO-**staff/jcastro/CASPER/**
> Spectrometer/Humps_in_the_**stop_band.PNG
> ftp://ftp.cv.nrao.edu/NRAO-**staff/jcastro/CASPER/**
> Spectrometer/No_Humps_in_the_**stop_band.PNG
>
> These humps are not present when the same signal is measured on a spectrum
> analyzer, so I'm fairly certain that these humps are not real and are
> produced inside the Roach spectrometer.  The occurrence of these humps is
> very predictable.  With acc_len set to 10 the humps occur with the
> pattern of every 6th, 7th, 6th, 7th, 6th, 7th, 6th, 7th, 7th acc samples.
>  To me, something this predictable points to a problem in the digital
> design.  A plot of the time between humps can be seen here:
>
> ftp://ftp.cv.nrao.edu/NRAO-**staff/jcastro/CASPER/**
> Spectrometer/Humps%20in%20the%**20stop%20band%20time%**
> 20between%20humps.PNG
>
> Has anyone else seen this behavior?  Any ideas of what it is and how to
> get rid of it???
>
> Thanks,
>
> Jason Castro
> NRAO
>
>