Hi Benjamin, I haven't read the full thread, so not sure if you detailed sampling frequencies, etc., but in our testing of ROACH and ROACH2, we found the biggest culprit to be a bus signal that never leaves the PowerPC, and (if memory serves) causes the biggest spur at 133 MHz (and of course harmonics). Depending on where these fall in your band, you may get interplay between interleaving artefacts and real interferers.
Regards, Francois On Fri, 9 Apr 2021 at 08:14, Clifford van Dyk <cliffordvan...@gmail.com> wrote: > Hi Benjamin > > When presented with a pure tone input, INL usually exhibits as a few > low-order (2nd, 3rd harmonic) spurs in a spectrum, that can be reduced by > high dither levels (in the order of half you ADCs usable dynamic range). > DNL, on the other hand, typically exhibits as many high order spurs (many > higher harmonics that alias back) that can be reduced by dither in the > order of your quantisation step size. Its easy to appreciate this by > considering a polynomial expansion of the ADCs transfer function - the ADCs > staircase requires many terms (=high order harmonics) to represent > accurately by polynomial expansion, whereas INL can be represented by just > a few terms. It is therefore not surprising to me that you could not solve > the many spurs by injecting a large scale sinusoidal dither - they are not > typically caused by INL. > > Certain combinations of signal frequency to sample clock frequency or > signal amplitude to quantisation level can result in apparent periodicity > in the resultant digitized signal rather than noise that is evenly > distributed in the spectrum. > > It is possible to produce clean spectra to well below -110 dBFS using > lower sample rate, higher linearity ADCs and low input signal level (50 ohm > terminated inputs), but when presented with a near Fs signals, linearity > inevitably becomes the limit on dynamic range/sensitivity due to DNL and > quantisation effects. I can send you some plots of what we have achieved > with 16-bit ADCs (at far lower sample rates) if you are interested. > > Kind regards, > Clifford > > On Fri, 09 Apr 2021, 03:17 'Benjamin Godfrey' via > casper@lists.berkeley.edu, <casper@lists.berkeley.edu> wrote: > >> Thank you everyone for all the great input. I haven't been able to try >> anything substantive yet but I definitely have a laundry list of things to >> try. >> >> Clifford: I've done signal injection tests with sinusoids and seen >> similar spurs but haven't done a careful check to ensure that the injected >> signal doesn't have harmonics and things on it. Same goes with >> investigating the clock. I have a commercial spectrum analyzer that I use >> to check both of those. You're also right that the ADC isn't shielded from >> the ROACH (at least with a Faraday shield). >> >> On the dither front, I tried measuring the INL of the ADC using the known >> pdf of a sine wave. This was then used to create a lookup table that I >> applied to the time-series data before taking the FFT. Unfortunately, it >> didn't do a whole lot to the spurs. My setup for looking at these spurs >> (and my result) is likely sub-optimal though (my thinking is explained in >> the following paragraph) so this is something I should continue thinking >> about. >> >> Dan: A little bit more detail about the ultimate goal: The challenge is >> to detect a 1 ppm spectrally pure signal (varying only on 12-hour >> timescales) at femto-volt levels. Since the frequency is unknown we want to >> maximize the spectral range but to ensure maximum sensitivity we also want >> to ensure that we're as efficient as possible scanning over that spectral >> range (aka do it in real time). That's currently what is setting the FFT >> size. It also means that the data we're feeding into the ADC is basically >> thermal noise, which we then average many, many times over to be as >> sensitive as positive. That was my underlying motivation for doing all this >> spur testing by terminating the ADC input. I'm absolutely not beholden to >> this method though, and I think some more reading is in order on my end in >> light of your suggestions. >> >> Matt: Good segue from what Dan was suggesting. Thanks for the reading >> material. This is all new to me so the more resources the better. >> >> Atul: That's very good to know. These spurs are showing up every ~15,500 >> bins. But I'll go through the code and make sure I'm casting the ADC data >> before sending it to the GPU. >> >> Once again, thanks everyone for all the great insight. >> Looking forward to trying things out, >> Ben >> >> >> >> >> On Thu, Apr 8, 2021 at 4:42 PM Atul Ghalame <atul.ghal...@gmail.com> >> wrote: >> >>> Hi Ben, >>> >>> I had experienced a similar problem once with the 64 channel ADC+ROACH. >>> F-engine was running on ROACH and all fixed-point data, mismatch of data >>> type+bits created dips in the broadband noise test at regular intervals. >>> Casting ADC data into expected format before the FFT resolved it. >>> >>> While katADC is sending fixed-point data and GPU running on floating >>> point, somewhere this conversation has not happened correctly, simple >>> typecasting into 32 bits won't help. If you convert Hz into FFT bins and >>> observe spurs at bin numbers of 2's power, it might be a digital noise >>> created in F-engine. Twiddle factors may become dominant when an >>> interpreted input signal by F-engine is low. >>> >>> If that GPU code was well tested in the same way before, then it looks >>> like some other problem. >>> >>> Best regards, >>> Atul Ghalame >>> ---------------------------------------------- >>> Non-Imaging Processing Engineer, >>> The University of Manchester. >>> >>> On Thu, Apr 8, 2021 at 9:42 PM 'Benjamin' via casper@lists.berkeley.edu >>> <casper@lists.berkeley.edu> wrote: >>> >>>> Hi everyone, >>>> This question is a little out of left field, but I know there's lots >>>> of experience in this regime. I'm working on an experiment looking for a >>>> Q~10^6 signal embedded in broad-spectrum noise. To this end, we are using a >>>> ROACH-2 board with a katADC, to sample the incoming signal, and then >>>> offloading the data to a PC where a GPU performs a (large) FFT. Any >>>> candidate signal will look like excess power in just a single bin. >>>> (In part) Because of this, we're very concerned with identifying the >>>> source of any spurs that we see in our FFT spectra. For the past little bit >>>> I've been doing some very simple tests where I terminate the input to the >>>> ADC, take data, do an FFT, and look at the resulting spectrum. An example >>>> is shown below: >>>> >>>> [image: AttenTest_0_EnableOff_ClosedTop_2GHz_FFT_Zoom_4-4-21.png] >>>> >>>> *2^26-point FFT sampling at 2 GHz (interleaved mode) zoomed in between >>>> 490-510 MHz. For this test, ADC input was terminated and enable register >>>> was set to 0.* >>>> >>>> >>>> When I do this, I get results like the above, where I notice a couple >>>> of things: Firstly, there is a large clock spur at 500.0 MHz. Ultimately, >>>> this will have to be dealt with, but the source of it is known. Secondly, >>>> there are a bunch of much smaller spurs. These are all separated by ~923 >>>> kHz from each other, and they are seen across the entire spectral range >>>> (from 0 all the way to 1 GHz). Actually, at lower frequencies you see spurs >>>> every 462-463 kHz. >>>> >>>> One further thing I've noticed is that if I set the programmable >>>> attenuator to it's maximum (31 dB), the spurs disappear but the main clock >>>> spur remains at its original amplitude. With all that in mind, this leads >>>> me to a few questions: >>>> >>>> - Has anyone dealt with these spurs before? >>>> - Do you have any hypotheses what their origin may be? I've been >>>> concerned about switching power supplies (namely the ATX and the >>>> DC-to-DC >>>> converters) but those are on the ROACH not on the katADC. Plus, from the >>>> schematics, it looks like there's a lot of filtering happening both on >>>> the >>>> ROACH and the katADC. >>>> - Do you have any suggestions for getting rid of these spurs? >>>> >>>> Any insight is greatly appreciated. >>>> Many thanks, >>>> Ben >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "casper@lists.berkeley.edu" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to casper+unsubscr...@lists.berkeley.edu. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/fd9296d0-a9b6-4aa8-91f4-0ae64115f639n%40lists.berkeley.edu >>>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/fd9296d0-a9b6-4aa8-91f4-0ae64115f639n%40lists.berkeley.edu?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "casper@lists.berkeley.edu" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to casper+unsubscr...@lists.berkeley.edu. >>> To view this discussion on the web visit >>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAKwPaONVw91eZu6_T1GdmQv779qO_dW_sohUMVeqt5b7AKAFoQ%40mail.gmail.com >>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAKwPaONVw91eZu6_T1GdmQv779qO_dW_sohUMVeqt5b7AKAFoQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "casper@lists.berkeley.edu" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to casper+unsubscr...@lists.berkeley.edu. >> To view this discussion on the web visit >> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAERfaAiYQqqhwdUzz3vCfh4M6vggTnu3vjrPH3RHubxzB572CA%40mail.gmail.com >> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAERfaAiYQqqhwdUzz3vCfh4M6vggTnu3vjrPH3RHubxzB572CA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To view this discussion on the web visit > https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAB4rdAKKAQDNaqBUHtnCKxKxopP3eO-vFDVc6zBD-GX3T0z4KQ%40mail.gmail.com > <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAB4rdAKKAQDNaqBUHtnCKxKxopP3eO-vFDVc6zBD-GX3T0z4KQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAB4_c0q4oVGP4e-zZ7KwHa%3DqS_w_6iswOfB1sHTQXPyhLV-efA%40mail.gmail.com.
