Hi All, On 17 September 2012 09:34, Jason Manley <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> 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> 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 > > > > > > > > >
