Hi Jonathan,
Sorry for the confusion, describing a problem like this is more difficult than
I first anticipated.
In our code basically the first things we do are:
- Doing the MMCM calibration:
opt1, glitches1 = adc.calibrate_mmcm_phase(fpga, 1, ['snapshot1',])
- Clear the OGP registers:
rww_tools.clear_ogp()
- After this we calculate the calibration coefficients (gain. offset and
amplitude)
- Then we try to write them back to the OGP registers
rww_tools.set_offs(t[0], t[3], t[6], t[9])
rww_tools.set_gains(t[1], t[4], t[7], t[10])
rww_tools.set_phase(t[2], t[5], t[8], t[11])
Furthermore we got the code from the following location:
https://github.com/sma-wideband/adc_tests
And we modified it, if you'd like I can send you are files.
And for the last question: I did a quick check and this is a rev-2 board.
Kind regards,
Tom
________________________________________
Van: Jonathan Weintroub [jweintr...@cfa.harvard.edu]
Verzonden: vrijdag 12 september 2014 21:05
Aan: Geelen, T.F.G.
CC: David MacMahon; CASPER Mailing List
Onderwerp: Re: [casper] Problem calibrating ADC for ROACH2
Hi Tom (and Ricardo),
Thanks for the clarification, there was initially some question here as to
whether the “calibration” you refer to is MMCM clock calibration (which sets up
the ADC to ZDOK interface), or the quad core calibration. Based on your
response you mean quad core calibration. In any event could you please clarify
if you are completing the MMCM calibration too (which would need to be done
before the quad core calibration).
Dave’s suggestion is worthwhile, but if I was to guess, the likelihood of a bad
solder joint on the ZDOK is low. Switching the ADCs was a good experiment, at
least you know both ADCs work now. We vote for a bug in the software being the
most likely cause, probably a small thing like setting a variable to specify
ZDOK# or similar. These things are, as you might understand, quite difficult
to debug from a distance, so there is nothing for it but to comb through your
code carefully.
Something that is not clear is exactly what software you are using. You
reference the paper by Patel et al., and then say you are using “the code
provided”, however I to my recollection we never posted specific code with that
paper. Could you please specify exactly what code you refer to? Is this a
GitHub download etc? Also could you confirm you are using a ROACH2 Rev2 board?
The reason this is relevant is one ZDOK is wired somewhat differently on the
two revs, so this could perhaps have a bearing?
Best,
Jonathan
on Sep 12, 2014, at 2:02 PM, Geelen, T.F.G. <t.f.g.gee...@student.tue.nl> wrote:
> Hi Dave,
>
> Thanks for the suggestion. I will look into this and see what comes out.
>
> Regards,
>
> Tom
> ________________________________________
> Van: David MacMahon [dav...@berkeley.edu] namens David MacMahon
> [dav...@astro.berkeley.edu]
> Verzonden: vrijdag 12 september 2014 19:07
> Aan: Geelen, T.F.G.
> CC: CASPER Mailing List
> Onderwerp: Re: [casper] Problem calibrating ADC for ROACH2
>
> Hi, Tom,
>
> I suggest using an oscilloscope to probe the SPI signals on the ZDOK0 ADC
> card while writing to it. Based on this schematic:
>
> https://casper.berkeley.edu/wiki/images/d/d2/Schematic_ADC_A2_5G_DMUX11.pdf
>
> ...it looks like you can probe them at CN5 or CN2 since you know the cards
> themselves are good (since they both work OK in ZDOK1).
>
> You might find that one of the SPI signals is not present (e.g. maybe because
> of a bad solder joint on the ZDOK connector). Or you might find that none of
> the SPI signals are present (e.g. maybe because of a software bug).
>
> Hope this helps,
> Dave
>
> On Sep 12, 2014, at 6:28 AM, Geelen, T.F.G. wrote:
>
>> Hi,
>>
>> Here is some clarification.
>>
>> To be precise it seems impossible to calibrate the ADC board connected to
>> ZDOK0. (the other one than Ricardo mentioned). We have a script which tries
>> to calibrate the 4 cores inside the ADC board considering phase,amplitude
>> and offsets.
>>
>> So what we do is essentially the following:
>> - We take a snapshot of the ADC output when it is still uncalibrated using a
>> 10 MHz sine wave on the input.
>> - We calculate the gain, offset and phase of the received signal to balance
>> the cores
>> - We write the values back to the OGP registers in the ADC.
>> - We take a second snapshot to check if it worked.
>>
>> For the ADC connected to ZDOK1 this all seems to go fine and the resulting
>> wave is a perfect sine wave. When we try to write however to the ADC in
>> ZDOK0 it does not seem to respond.
>> The resulting sine wave is still exactly the same and it seems the OGP
>> registers do not get written.
>>
>> Furthermore if we switch the actual ADC boards from ZDOK it seems that the
>> problem stays in ZDOK0.
>>
>> Parameters we use:
>> - demux 1:1 mode
>> - single channel mode
>> - ADC board: https://casper.berkeley.edu/wiki/ADC1x5000-8
>>
>> Kind regards,
>>
>> Tom
>> ________________________________________
>> Van: casper-boun...@lists.berkeley.edu [casper-boun...@lists.berkeley.edu]
>> namens Geelen, T.F.G. [t.f.g.gee...@student.tue.nl]
>> Verzonden: dinsdag 9 september 2014 17:19
>> Aan: CASPER Mailing List
>> Onderwerp: [casper] Problem calibrating ADC for ROACH2
>>
>> Hi everyone,
>>
>> We have trouble here in the laboratory trying to calibrate the ADC's for our
>> ROACH2. It is still the same problem we had been having a month ago.
>>
>> We started working with the paper: 'CHARACTERIZING THE PERFORMANCE OF A
>> HIGH-SPEED ADC FOR THE SMA DIGITAL BACKEND' and the code provided.
>> Modifying the code as necessary we have been succesfully able to calibrate
>> the ADC connected to ZDOK1. The other ADC however does not seem to get
>> calibrated at all.
>> We checked if it was a hardware issue by switching the ADC's from ZDOK port
>> and the problem switched too. Somehow the ADC board in ZDOK0 is not
>> calibrated correctly.
>>
>> Since it works on one perfectly and not on the other the obvious place to
>> look was in our code but so far we have not been able to find a mistake in
>> the code. At the moment we are a bit stuck as to ideas what could be causing
>> this problem.
>>
>> Any suggestions from the community?
>>
>> Regards,
>>
>> Tom
>
>
