Hi Dan After doing what you advised me, I managed to observe the following:
When I adjust the accumulation length to 2048 everything works correctly, then I adjust the accumulation length to 1024 and everything continues to work fine, then I adjust the accumulation length to 512 and the PC stops receiving the UDP packets (totally) ... Then I go back to 1024 and I no longer get packets. Then I go back to 2048 and everything goes back to normal, then I adjust the value to 1024 and it works correctly. I no longer see UDP packets when I adjust the value to 512 ... Can it be a problem with my network card? Regards 2018-03-05 19:15 GMT-06:00 Dan Werthimer <d...@ssl.berkeley.edu>: > > hi rolando, > > it's possible that the problem you see is because your sample rate has > changed > or the valon's power output is too low for the adc. > > the valon display can sometimes mislead. > i suggest you power cycle the valon, and re-program it with the settings > you want > (don't use the flash to boot it). > and measure the valon output frequency and power level, (or check the > packet rate coming from your spectrometer). > > we've seen the valon's flash get reprogrammed by accident. and check the > valon output > > also, after you change the valon, or disconnect the clock from the adc, > make sure to re-program the fpga: > if you have a runt clock pulse when changing clock rates, the fpga can get > into a wierd mode. > > dan > > > On Mon, Mar 5, 2018 at 5:08 PM, Rolando Paz <flx...@gmail.com> wrote: > >> Hi Dan >> >> Right now I did another test with accumulation length = 1024, and it did >> not work ... then I changed it to 2048 and now it's the new value with >> which ROACH works ...something bad is happening. >> >> The settings of the 5008 valon can be seen in the attached image. >> >> The QUADC needs (https://casper.berkeley.edu/wiki/ADC4x250-8): >> >> Inputs >> Clock: 24-250MHz 50Ohm 0dBm >> >> According to what I see in the image "input_to_quadc.png" that I obtained >> with an oscilloscope, the signal that input to the quadc is -5.5dBm. >> >> Could this be the problem? >> and if this were the problem, why before everything worked well? >> >> Best Regards >> >> Rolando >> >> 2018-03-05 17:46 GMT-06:00 Dan Werthimer <d...@ssl.berkeley.edu>: >> >>> >>> hi rolando, >>> >>> are you dropping packets? >>> >>> have you used tcpdump or other packet sniffer code (eg: gulp...), >>> to investigating what's going on when you change the integration time? >>> >>> is the number of packets/second correct for the integration time you set? >>> if not, perhaps you accidently changed the sample clock to the adc >>> so the integration time is shorter than before... >>> >>> best wishes, >>> >>> dan >>> >>> >>> >>> On Mon, Mar 5, 2018 at 3:39 PM, Rolando Paz <flx...@gmail.com> wrote: >>> >>>> Hello >>>> >>>> I'm having a problem with my 10G ethernet card (I think)... everything >>>> was working fine the last year. Yesterday I turned on the ROACH again and >>>> now I could not get data with the original settings (accumulation length= >>>> 256). Maybe the drivers of the Myricom 10G-PCIE-8A-C card were updated >>>> automatically in my ubuntu 16.04LTS :( >>>> >>>> These are the original settings: >>>> >>>> Notes: >>>> a) ROACH1 design, 4 inputs with QUADC >>>> b) "fft_biplex_real_2x" block was used >>>> >>>> FFT points (FFT size) = 2048 >>>> Samples per clock = 1 >>>> FFT clock cycles = 2048 >>>> Accumulation Length = 256 >>>> FPGA clock (MHz) = 200 >>>> Integration Time = 0.00262144 >>>> >>>> But now it only works from: >>>> >>>> FFT points (FFT size) = 2048 >>>> Samples per clock = 1 >>>> FFT clock cycles = 2048 >>>> Accumulation Length = 1024 >>>> FPGA clock (MHz) = 200 >>>> Integration Time = 0.01048576 >>>> >>>> Before I managed to obtain data with a time of integration of >>>> 0.00262144, and now only from 0.01048576 >>>> >>>> What could happen? >>>> >>>> Regards >>>> >>>> Rolando >>>> >>>> -- >>>> 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 post to this group, send email to casper@lists.berkeley.edu. >>>> >>> >>> -- >>> 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 post to this group, send email to casper@lists.berkeley.edu. >>> >> >> -- >> 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 post to this group, send email to casper@lists.berkeley.edu. >> > > -- > 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 post to this group, send email to casper@lists.berkeley.edu. > -- 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 post to this group, send email to casper@lists.berkeley.edu.
