Hi Mandana
I have just had a look at the python script in svn (poco_init.py)
and (as far as I can tell), the status bits are never cleared. This
means that these are not a true reflection of the current state of
what is happening.
To clear the status register, a positive edge ('0' then '1') needs
to be written to bit 16 of the ctrl register. You could do this
in the python script, or from the kat_cp telnet interface.
Hope this helps.
Regards
Andrew
On 4 March 2011 07:35, <[email protected]> wrote:
> Hi,
>
> I tried lowering the input levels, but fft_over bits are always set. They
> are also set for terminated inputs. I also applied -10dBm 100MHz
> band-limited white noise and fft_over is set.
>
> I was using Sept2 git release of mlib_devel. I just downloaded the latest
> libraries to see if it makes any difference.
>
> Jason, do you have any suggestion or provision on how to deal with the
> (small) DC bias in the ADC then? When you were running tut4 on Roach, did
> you notice whether fft_over bits were being asserted?
>
> mandana
>
> >
> >
> > hi jason,
> >
> > i agree there's a small DC bias in the ADC,
> > but it's not sufficient to cause an FFT overflow.
> >
> > dan
> >
> > Jason Manley wrote:
> >> The DC bias comes from the ADC itself, which is biased to be symmetrical
> >> about -0.5 (not 0).
> >>
> >> Jason
> >>
> >>
> >> On 03 Mar 2011, at 01:42, Dan Werthimer wrote:
> >>
> >>
> >>> hi andrew, mandana,
> >>>
> >>> i think all the casper adc boards
> >>> have balun transformers or ac coupling
> >>> capacitors, so a signal's DC bias
> >>> can't get to the ADC.
> >>>
> >>> dan
> >>>
> >>> On 03/01/2011 10:44 PM, Andrew Martens wrote:
> >>>
> >>>> Hi Mandana
> >>>>
> >>>>
> >>>> fft_shift is set to 0xffffffff by default in tutorial 4 poco
> >>>> design. Any other suggestions?
> >>>> When I monitor my ADC input levels, they are about 4.6 bit used.
> >>>>
> >>>>
> >>>> Ok, well that should rule out overflows from the FFT.
> >>>>
> >>>> I assume that there is no clipping with terminated inputs?
> >>>> At what power level does overflow _not_ happen?
> >>>>
> >>>> Is there any DC bias in your input signal? A DC blocking filter is
> >>>> good here as this may be causing overflow in the FFT.
> >>>>
> >>>> The DC channel will often cause the equaliser overrange bit to be set
> >>>> as the value in this channel is much larger than the others. This is
> >>>> not
> >>>> a problem as long as there is no overflow in the FFT.
> >>>>
> >>>>
> >>>>> My next question is what is the dip that I see in the middle
> >>>>> of the auto- and cross-correlation plots, regardless of
> >>>>> signals applied or just terminated inputs.
> >>>>>
> >>>>> Not so sure about this, possibly include a plot if you can.
> >>>>>
> >>>> Please see the attached plot. I have a Roach board and 2 x 1GS/s
> >>>> ADC
> >>>> boards. In this plot, a 500MHz sine is connected to the first input
> >>>> (channel a), while the other 3 inputs are terminated (channels b,
> >>>> c,
> >>>> d) and an 800MHz clock is supplied. What is the small dip in the
> >>>> centre (@channel 500). This is also present in the plot posted on
> >>>> page 15 of casper_workshop_tut4.pdf.
> >>>>
> >>>> I have no idea to be honest. There are some artifacts but there
> >>>> has not been a study on what these are and what causes them
> >>>> yet. They are generally very small, stable and can be catered
> >>>> for in any final system.
> >>>>
> >>>> Sorry I have not been more useful.
> >>>>
> >>>> Regards
> >>>> Andrew
> >>>>
> >>> --
> >>>
> >>> Dan Werthimer
> >>> Space Sciences Lab and Berkeley Wireless Research Center
> >>> University of Calfornia, Berkeley
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
>
>
>
