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 <jman...@ska.ac.za
<mailto:jman...@ska.ac.za>> 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 <d...@ssl.berkeley.edu
<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 <jcas...@nrao.edu
<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/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 100000 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
>
>
>
