Hi Sharat, Tomorrow (in California) I'll send you a link and instructions to use the calibration script I have, which should work ok at 2500mhz clock.
In the meantime, it might not matter, but what version of mlib-devel are you using? Cheers, Jack On Thu, 3 Sep 2015 9:02 pm sharat varma <va...@hku.hk> wrote: > Hi, > > Thanks for the reply and sorry for the delayed response. > Yes, the x-axis represent the time and y-axis represents the signed 8 bit > output. The negative bias is due to the nature of the input. > > I was trying to use the files in the link you mentioned, but I keep > getting the error shown below. I am using the bof file provided for roach2. > > test roach connectivity ... ok > check if requested bof is available ... ok > test roach pingability ... ok > program the requested bof ... ok > estimate clock rate, should be within 1 MHz of expected ... ok > confirm the design has the ADC SPI controller ... ok > confirm the design has the needed scope ... ok > test if calibration finds optimal MMCM phase ... FAIL > > ====================================================================== > FAIL: test if calibration finds optimal MMCM phase > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "test_adc5g.py", line 107, in test_optimal_solution_found > self.assertIsNotNone(self._optimal_phase) > AssertionError: unexpectedly None > > ---------------------------------------------------------------------- > Ran 8 tests in 7.230s > > FAILED (failures=1) > > Please let me know if I am doing anything wrong or where could be the > problem. > > For your information: > > System: roach2 > > ADC : ASIAA ADC5G ADC > > Clock : 2500MHz. > > Thanks and regards, > > Sharat > > > On 1 September 2015 at 23:01, Primiani, Rurik <rprimi...@cfa.harvard.edu> > wrote: > >> Hi Sharat, >> >> The plot you provided has no labels or units so I will assume the x-axis >> represents time in samples and the y-axis represents signed 8-bit sample >> values. I'm not sure why there is such a negative bias but perhaps that's >> particular to your instrument. >> >> Please, at the very least, run the MMCM calibration described at >> https://github.com/sma-wideband/adc_tests to reduce glitches on the >> interface. I believe Jack also has a more sophisticated approach which >> adjusts the IODELAY for each individual data line; sadly I don't have a >> link handy for that. >> >> Although you may not see these glitches with a sine wave, a noise-like >> signal will cause more transitions on each bit and thus more glitches with >> an uncalibrated interface. >> >> Thanks, >> Rurik >> >> >> >> On Tue, Sep 1, 2015 at 2:54 AM, sharat varma <va...@hku.hk> wrote: >> >>> Hi Jack, >>> >>> Thanks for the reply. >>> >>> I did not run mmcm calibration. Actually, we checked the ADC by feeding >>> it a low frequency sine wave from a function generator and it works fine. >>> >>> The problem with spikes occurs when we feed the ADC with the >>> photo-detector output. >>> >>> Regards, >>> Sharat >>> >>> >>> On 1 September 2015 at 13:52, Jack Hickish <jackhick...@gmail.com> >>> wrote: >>> >>>> Hi Sharat, >>>> >>>> Are you running the adc mmcm calibration routine after programming your >>>> roach? >>>> >>>> Cheers, >>>> Jack >>>> >>>> On 31 August 2015 at 22:41, sharat varma <va...@hku.hk> wrote: >>>> >>>>> >>>>> Hi Casper, >>>>> >>>>> I am working as a post-doc working under guidance of Dr. Hayden So at >>>>> The University of Hong Kong. >>>>> >>>>> We are using ROACH2 to capture data from optical cytometry. We are >>>>> using ASIAA ADC5G ADC to capture data at 4 to 5 Gsps. >>>>> >>>>> We basically use the following parameters. >>>>> >>>>> Block parameter: two-channel, ZDOK0, demux 1:1 . >>>>> System: roach2, clock source:adc0_clk, clock rate: 300 MHz. >>>>> >>>>> We are connecting the output of a photo-detector 1544-B from Newport >>>>> Corp (the spec is attached) to the ADC input using SMA. >>>>> We find that noisy spikes are introduced when we capture the data >>>>> through the ADC (see attached fig). We double checked if the source had >>>>> problems using a oscilloscope, but on the oscilloscope we do not see any >>>>> of >>>>> these spikes. >>>>> >>>>> We would be grateful if you could let us know if we are doing anything >>>>> wrong. >>>>> >>>>> Rgards, >>>>> Sharat >>>>> >>>>> >>>>> >>>> >>> >> >
