Thanks. I figured it out enough to move on. The following initialization code works, but if I switch the order of the last two lines (rampTest and selectInput), I basically the bad pattern of near-zero values that I originally emailed about:
adc = casperfpga.snapadc.SnapAdc(fpga, num_chans=1, resolution=8, ref=10) adc.init(sample_rate=800, numChannel=1) adc.selectADC() # same as adc.selectADC([0,1,2]) adc.rampTest(retry=True) adc.adc.selectInput([1,1,1,1]) Wei Liu's code helped because it gave me the idea to call rampTest() first. Is rampTest() the only "calibration" that Wei Liu's code is doing? rampTest() calls alignLineClock() and alignFrameClock(). Is this all that you mean by "calibration"? Not some fine-tuning or balancing of gains or delays for different sub-ADCs, which then get interleaved together? I was calling selectInput() before rampTest() because it made sense to select the input configuration before testing it. Neither function's docs had anything to say about the relative calling order. adc.set_gain() still does nothing, even when called where Wei Liu's code calls it. Where in the startup process should this get called? The py38-dev and py38 branches of casperfpga differ in only trivial ways in snapadc.py. Maybe the changes you spoke of have already been merged into py38? As for the build error, I've only tried SNAP tutorial 1 and 3 and I got the error for both. Once Xilinx finally gets back to me about an academic license, I'll be able to try it on my RFSoC 4x2. Does it normally take more than a month to process a donation request? I've asked twice. Thanks, Jason On Sat, May 13, 2023 at 1:22 AM Jonathon Kocz <[email protected]> wrote: > Jason, > > I think the data problem is with the ADC calibration. - And I agree, the > inconsistent renames were hugely frustrating. Sorry you've hit these > errors. The original SNAP calibration routine did not work with python3 and > needed to be rewritten entirely. It was left in a broken state for a while > as the merged commit didn't fix the various issues and updated some of the > syntax. > > A working version has recently been merged into the py38-dev branch of > casperfpga: https://github.com/casper-astro/casperfpga/tree/py38-dev > > The tut script will need updating, but an example adc calibration code > developed by Wei Liu is here: > https://github.com/liuweiseu/limbo_scripts/blob/lab_test/ipynb/snap_adc.ipynb > > I'm not sure about the build error - does this only occur for SNAP builds, > or any build? > > Best, > Jonathon > > > > > On Fri, 12 May 2023 at 05:03, Jason Gallicchio <[email protected]> wrote: > >> I had the same issue and still do. I see similar spikes, even with a >> signal. It's because I see zero or near-zero samples that occur in groups >> of 8. (See attached.) >> >> I've attached my snapshot from fpga.devices['adc'].read(man_trig=True). >> >> I get a similar result from calling adc.readRAM()[0].reshape(128*8) >> >> It's not as obvious that this pattern exists for low-power inputs. I saw >> the same spectrum as in the original post when I had no or small input >> because of the regular pattern of zeros hidden in the near-zero noise. >> >> I have NOT figured out why this is happening. It happens when I use any >> of the 3 ADC chips. It happens for sampling frequencies slower than 800 MHz. >> >> I don't know how to tell if it's a hardware problem or (more likely) a >> configuration one -- the tutorial didn't work out of the box. >> >> I started with the python code on the main branch of tutorials_devel: >> >> https://github.com/casper-astro/tutorials_devel/blob/main/snap/tut_spec/snap_tut_spec.py >> >> >> However, I had to do several things to get even this far: >> >> * convert the python2 code to python3 to work with the py38 branch of >> casperfpga >> >> * Do my own initialization after calling init(): I called >> either adc.rampTest(retry=True) (which passes) or adc.alignLineClock() >> and adc.alignFrameClock(). I might have to call these manually now because >> of the cryptic "Snipped off ADC calibration here;" comment in >> https://github.com/casper-astro/casperfpga/blob/py38/src/snapadc.py#L269 >> and I'm not sure what other steps I should be taking here. >> >> * Wonder why adc.set_gain(gain) doesn't seem to do anything. Maybe I >> should be playing with adc.adc.cGain() and adc.adc.fGain()? Does this need >> to get called before or after some other initialization step? >> >> * Wonder why some functions seem to have been inconsistently renames that >> I manually tweaked, like >> - casperfpga.snapadc.SnapAdc = casperfpga.snapadc.SNAPADC >> - adc.testPatterns = adc.test_patterns >> - adc.select_adc = adc.selectADC >> - adc.controller = type(adc.adc) >> >> * liberally interpret references to ROACH in the docs >> https://github.com/casper-astro/tutorials_devel/blob/main/docs/tutorials/snap/tut_spec.md >> >> >> I am using the random Raspberry Pi 3b+ image I got from the google drive >> link on: >> https://www.mail-archive.com/[email protected]/msg07317.html >> because the link on the more official Bringup page had issues that I no >> longer remember: >> https://casper.astro.berkeley.edu/wiki/SNAP_Bringup >> >> I get the same bad data whether I use the pre-built snap_tut_spec.fpg and >> also my own build. Admittedly, this is only my second simulink jasper build >> after tutorial 1, and these builds always end with >> FileNotFoundError: [Errno 2] No such file or directory: >> '.../tutorials_devel/snap/tut_spec/snap_tut_spec/myproj/myproj.runs/impl_1/top.xsa' >> >> If I get these things figured out, I'd be happy to do a pull request for >> or whatever would be helpful. >> >> Thanks, >> Jason >> >> On Monday, January 21, 2019 at 5:50:50 PM UTC+11 James Smith wrote: >> >> Hello David, >> >> A little late to the party but I thought I'd throw in 2c from our >> perspective. >> >> The other thing we usually try to do with ADCs (this was an issue on the >> ROACH1s) is to put in a bit of white noise with whatever test signal we >> were using (sine wave usually). When you get actual sky, then you will have >> to fiddle with signal levels again until you get an optimum, because the >> sky signal will invariably be different from your lab test signals. >> >> Regards, >> James >> >> >> On Fri, Jan 18, 2019 at 7:37 PM David Marsh <[email protected]> wrote: >> >> Thank you Dan! >> >> Using the adc snapshot, I saw that with no input the adc was toggling >> between -1 and 0. This was the cause of the >> spikes in the spectrum. I also looked at the adc samples with a sine wave >> as the input and everything looked as >> expected as you described. >> >> Thanks, >> David >> >> >> >> On Tue, Jan 15, 2019 at 11:07 AM Dan Werthimer <[email protected]> >> wrote: >> >> >> hi david, >> >> when you have no signal going into an adc, it will typically chatter >> between two values, around -1, 0 and +1, >> and you'll see a lot of RFI and interleave spurs, so the spectrum you >> sent around doesn't surprise me, >> >> but if you put in a sine wave that is much larger than the ADC chatter, >> say Vpp ranging from -100 to +100 (out of -128 to +127 for an 8 bit ADC), >> then the power spectrum spurs should be very small compared to the sine >> wave power >> (about a factor of 10,000 in power (100 in voltage)). >> >> can you use the adcsnap shot to look at the samples coming from your adc, >> and see what the relative levels are of the sine wave to the noise? >> does the power spectrum agree with what you see in the snapshot? >> >> best wishes, >> >> dan >> >> >> >> >> On Tue, Jan 15, 2019 at 9:59 AM David Marsh <[email protected]> wrote: >> >> Hi all, >> >> Sorry if this has already been explained/solved. >> I programmed Tutorial 3 onto a SNAP board and noticed some unexpected >> spikes in the spectrum. I have set up the hardware as explained in the >> python script with a 10 MHz, 8dBm reference going into the SYNTH_OSC SMA >> (3rd SMA from the left). >> >> The attached figure shows the spectrum with no input going into the SNAP >> board. There are large spikes in the spectrum every 50 MHz with the largest >> at 200 MHz. >> >> When I add a signal to the SNAP board, I can see it in the spectrometer >> at the correct frequency >> but the other spikes are still present. >> >> Do you know what is causing these spikes and how they can be removed? Any >> help would be greatly appreciated. >> >> Thanks, >> David >> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected]" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected]" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected]" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected]" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/8bf55f71-4082-42ec-bd8e-e76306040cb5n%40lists.berkeley.edu >> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/8bf55f71-4082-42ec-bd8e-e76306040cb5n%40lists.berkeley.edu?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAPU71P8mWPkavTUsLRY%3DbV_2Cxbk-XL300Z7E3smnn4Nba4ing%40mail.gmail.com > <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAPU71P8mWPkavTUsLRY%3DbV_2Cxbk-XL300Z7E3smnn4Nba4ing%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAFOBgPVYke-4VMXTfk7%3DD7%3Dks7TwCzagDsmtK5r3NWPpB_-qdg%40mail.gmail.com.
