Yes, it helps! Great. Mandana
On 03/03/2011 9:55 PM, Andrew Martens wrote:
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 AndrewOn 4 March 2011 07:35, <[email protected] <mailto:[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 >>> >>> >>> >>> >> >> > > >
