Wed May 2 12:23:16 2018, Alessio Berti, Peak at 0 mV in traces
|
Hi,
thank you for the quick reply. All the bins in the previous histograms have the same width. We also tried to plot the noise histogram for channel 2 with more bins (i.e. 1000, so that we can see almost discrete values), and the peak is still there.
Alessio & Davide
Stefan Ritt wrote: |
I note that your peak at zero is exactly twice as high as the bins left and right, so this looks to me like a binning problem in your histogramming. Maybe your bin #0 goes from -1mV to +1mV, which all other bins are just 1mW wide. Can you check that?
Stefan
Alessio Berti wrote: |
Hi,
we modified drs_exam.cpp to read all 4 channels from the DRS4 and apply directly the spike removal (taken from Osci.cpp) during the acquisition phase. For test purposes, we don't save the data showing spikes and we focus on the data not having spikes (even if at the end we end up having triple and quadro spikes which are not removed by the spike removal routine, but they are rare). With this modified program we wanted to characterize the noise of the DRS4, so we took 30000 events at 5GSPS, triggering on channel 1 with a 10 MHz sine wave with 100 mV_pp (trigger level set at 10 mV), while channels 2,3 and 4 were left open without any input.
We then took a look at the data and plotted the noise histograms for channels 2,3 and 4, which you can find attached (without offset correction, named zero_peak_after_spike_removal_ch*.png). For completeness, we also attached the plot from ch1 (the sine wave). The selections in time and amplitude we applied had the goal to remove the high oscillations in amplitude occurring in the first and last samples and to discard the quadro spikes we had in the data.
We see that there is a peak at 0 mV in all histograms from all channels and scanning through the data, we saw that indeed the value 0 mV is stored many times for each event, thus originating the peak we see in the histograms. We also applied an offset correction to the data (taking the average of the first three most occuring amplitudes) of channels 2 (as an example) and the problem seems to be only partially removed.
We also noticed that this peak at 0 mV is present also when we acquired the data from the DRS4 with DRSosc saving the data in binary format.
So we had the following questions:
- why is the DRS4 saving so many times the value 0 mV (exactly 0 mV)?
- is there any way (in our case through software, preferably at acquisition time) to solve this problem?
Thank you for the help and best regards,
Alessio & Davide
|
|
|
Fri May 4 11:35:20 2018, Stefan Ritt, Peak at 0 mV in traces
|
I tried the following:
- trigger on a 10 MHz sine wave on CH0, CH1 was open
- run drs_exam.cpp program and write data.txt with a few events
- imported the event into Excel
- did a histogram on (empty) CH1
What I see is a nice Gaussian distribution centered around 1mV, but with no spike around zero. See attachment. So I still believe that you have either a binning or a rounding problem. Like you round value -0.99 to +0.99 all to zero mV, and 1.00 to 1.99 mV to one mV.
Stefan
Alessio Berti wrote: |
Hi,
thank you for the quick reply. All the bins in the previous histograms have the same width. We also tried to plot the noise histogram for channel 2 with more bins (i.e. 1000, so that we can see almost discrete values), and the peak is still there.
Alessio & Davide
Stefan Ritt wrote: |
I note that your peak at zero is exactly twice as high as the bins left and right, so this looks to me like a binning problem in your histogramming. Maybe your bin #0 goes from -1mV to +1mV, which all other bins are just 1mW wide. Can you check that?
Stefan
Alessio Berti wrote: |
Hi,
we modified drs_exam.cpp to read all 4 channels from the DRS4 and apply directly the spike removal (taken from Osci.cpp) during the acquisition phase. For test purposes, we don't save the data showing spikes and we focus on the data not having spikes (even if at the end we end up having triple and quadro spikes which are not removed by the spike removal routine, but they are rare). With this modified program we wanted to characterize the noise of the DRS4, so we took 30000 events at 5GSPS, triggering on channel 1 with a 10 MHz sine wave with 100 mV_pp (trigger level set at 10 mV), while channels 2,3 and 4 were left open without any input.
We then took a look at the data and plotted the noise histograms for channels 2,3 and 4, which you can find attached (without offset correction, named zero_peak_after_spike_removal_ch*.png). For completeness, we also attached the plot from ch1 (the sine wave). The selections in time and amplitude we applied had the goal to remove the high oscillations in amplitude occurring in the first and last samples and to discard the quadro spikes we had in the data.
We see that there is a peak at 0 mV in all histograms from all channels and scanning through the data, we saw that indeed the value 0 mV is stored many times for each event, thus originating the peak we see in the histograms. We also applied an offset correction to the data (taking the average of the first three most occuring amplitudes) of channels 2 (as an example) and the problem seems to be only partially removed.
We also noticed that this peak at 0 mV is present also when we acquired the data from the DRS4 with DRSosc saving the data in binary format.
So we had the following questions:
- why is the DRS4 saving so many times the value 0 mV (exactly 0 mV)?
- is there any way (in our case through software, preferably at acquisition time) to solve this problem?
Thank you for the help and best regards,
Alessio & Davide
|
|
|
|
Tue May 8 12:15:54 2018, Alessio Berti, Peak at 0 mV in traces   
|
Hi Stefan,
following your example, we tried to perform the same measurement, using drs_exam and taking 1000 events. The results we obtained are in the plots attached (both in log and linear scale). We tried two different binnings:
- the first is the same as the one used in your example, that is 0.1 mV (corresponding to the plots having 81 bins)
- the second is a more wide binning equal to 0.35 mV, that is (2^(-11.5)) mV, 11.5 being the effective number of bits given in the DRS4 spreadsheet (corresponding to the plots having 23 bins)
With the fine binning we see that in the bin centered around 0 there is a little excess of events (the effect is more visible in the log scale histograms). This excess is not present in the wide binning case.
Is the problem we had before (and also here in the fine binning case) lying in the fact that we were trying to have bins with a width smaller than the effective resolution of the instrument (0.35 mV)?
We also noticed that in drs_exam, the values for the waveform are printed in the ASCII file with 1 digit after the decimal point, but when trying to print more digits the resolution is not improved (i.e. the decimal digits from the second one on are 0). This means that the values are rounded to a resolution of 0.1 mV when they are saved through the GetWave() routine (and in fact the member fPrecision is set to 0.1 -mV- in DRS.cpp, line 7502, and also in DRS.h, line 757, GetPrecision() returns 0.1). Why is that so? How does it reconcile with the effective number of bits giving a resolution of 0.35 mV?
Thank you,
Alessio & Davide
Stefan Ritt wrote: |
I tried the following:
- trigger on a 10 MHz sine wave on CH0, CH1 was open
- run drs_exam.cpp program and write data.txt with a few events
- imported the event into Excel
- did a histogram on (empty) CH1
What I see is a nice Gaussian distribution centered around 1mV, but with no spike around zero. See attachment. So I still believe that you have either a binning or a rounding problem. Like you round value -0.99 to +0.99 all to zero mV, and 1.00 to 1.99 mV to one mV.
Stefan
Alessio Berti wrote: |
Hi,
thank you for the quick reply. All the bins in the previous histograms have the same width. We also tried to plot the noise histogram for channel 2 with more bins (i.e. 1000, so that we can see almost discrete values), and the peak is still there.
Alessio & Davide
Stefan Ritt wrote: |
I note that your peak at zero is exactly twice as high as the bins left and right, so this looks to me like a binning problem in your histogramming. Maybe your bin #0 goes from -1mV to +1mV, which all other bins are just 1mW wide. Can you check that?
Stefan
Alessio Berti wrote: |
Hi,
we modified drs_exam.cpp to read all 4 channels from the DRS4 and apply directly the spike removal (taken from Osci.cpp) during the acquisition phase. For test purposes, we don't save the data showing spikes and we focus on the data not having spikes (even if at the end we end up having triple and quadro spikes which are not removed by the spike removal routine, but they are rare). With this modified program we wanted to characterize the noise of the DRS4, so we took 30000 events at 5GSPS, triggering on channel 1 with a 10 MHz sine wave with 100 mV_pp (trigger level set at 10 mV), while channels 2,3 and 4 were left open without any input.
We then took a look at the data and plotted the noise histograms for channels 2,3 and 4, which you can find attached (without offset correction, named zero_peak_after_spike_removal_ch*.png). For completeness, we also attached the plot from ch1 (the sine wave). The selections in time and amplitude we applied had the goal to remove the high oscillations in amplitude occurring in the first and last samples and to discard the quadro spikes we had in the data.
We see that there is a peak at 0 mV in all histograms from all channels and scanning through the data, we saw that indeed the value 0 mV is stored many times for each event, thus originating the peak we see in the histograms. We also applied an offset correction to the data (taking the average of the first three most occuring amplitudes) of channels 2 (as an example) and the problem seems to be only partially removed.
We also noticed that this peak at 0 mV is present also when we acquired the data from the DRS4 with DRSosc saving the data in binary format.
So we had the following questions:
- why is the DRS4 saving so many times the value 0 mV (exactly 0 mV)?
- is there any way (in our case through software, preferably at acquisition time) to solve this problem?
Thank you for the help and best regards,
Alessio & Davide
|
|
|
|
|
Tue May 8 14:43:03 2018, Stefan Ritt, Peak at 0 mV in traces
|
The DRS chip is read out with a 12 bit ADC, thus the phyical resolution is roughly 1V/4096 = 0.24 mV. I say roughly since the DRS has an analog gain of 0.98, which is corrected for. Now you have integer values which are converted into floating point numbers my multiplying them with ~0.24mV. If you then do histogramming with different bin sizes such as 0.1 mV and 0.35 mV , you get aliasing effects. The code truncates the result to 0.1 mV, which can give you also rounding artifacts. You will probalby see the same if you generate random 12 bit values and do the same histogramming. The 0.35 mV are not the RESOLUTION of the board (this is 0.24 mV as written above), but the Signal-To-Noise ratio of the DRS chip. If you measure zero volts at the input, and you make statistics over the distribution, you get an RMS of 0.35 mV.
Stefan
Alessio Berti wrote: |
Hi Stefan,
following your example, we tried to perform the same measurement, using drs_exam and taking 1000 events. The results we obtained are in the plots attached (both in log and linear scale). We tried two different binnings:
- the first is the same as the one used in your example, that is 0.1 mV (corresponding to the plots having 81 bins)
- the second is a more wide binning equal to 0.35 mV, that is (2^(-11.5)) mV, 11.5 being the effective number of bits given in the DRS4 spreadsheet (corresponding to the plots having 23 bins)
With the fine binning we see that in the bin centered around 0 there is a little excess of events (the effect is more visible in the log scale histograms). This excess is not present in the wide binning case.
Is the problem we had before (and also here in the fine binning case) lying in the fact that we were trying to have bins with a width smaller than the effective resolution of the instrument (0.35 mV)?
We also noticed that in drs_exam, the values for the waveform are printed in the ASCII file with 1 digit after the decimal point, but when trying to print more digits the resolution is not improved (i.e. the decimal digits from the second one on are 0). This means that the values are rounded to a resolution of 0.1 mV when they are saved through the GetWave() routine (and in fact the member fPrecision is set to 0.1 -mV- in DRS.cpp, line 7502, and also in DRS.h, line 757, GetPrecision() returns 0.1). Why is that so? How does it reconcile with the effective number of bits giving a resolution of 0.35 mV?
Thank you,
Alessio & Davide
Stefan Ritt wrote: |
I tried the following:
- trigger on a 10 MHz sine wave on CH0, CH1 was open
- run drs_exam.cpp program and write data.txt with a few events
- imported the event into Excel
- did a histogram on (empty) CH1
What I see is a nice Gaussian distribution centered around 1mV, but with no spike around zero. See attachment. So I still believe that you have either a binning or a rounding problem. Like you round value -0.99 to +0.99 all to zero mV, and 1.00 to 1.99 mV to one mV.
Stefan
Alessio Berti wrote: |
Hi,
thank you for the quick reply. All the bins in the previous histograms have the same width. We also tried to plot the noise histogram for channel 2 with more bins (i.e. 1000, so that we can see almost discrete values), and the peak is still there.
Alessio & Davide
Stefan Ritt wrote: |
I note that your peak at zero is exactly twice as high as the bins left and right, so this looks to me like a binning problem in your histogramming. Maybe your bin #0 goes from -1mV to +1mV, which all other bins are just 1mW wide. Can you check that?
Stefan
Alessio Berti wrote: |
Hi,
we modified drs_exam.cpp to read all 4 channels from the DRS4 and apply directly the spike removal (taken from Osci.cpp) during the acquisition phase. For test purposes, we don't save the data showing spikes and we focus on the data not having spikes (even if at the end we end up having triple and quadro spikes which are not removed by the spike removal routine, but they are rare). With this modified program we wanted to characterize the noise of the DRS4, so we took 30000 events at 5GSPS, triggering on channel 1 with a 10 MHz sine wave with 100 mV_pp (trigger level set at 10 mV), while channels 2,3 and 4 were left open without any input.
We then took a look at the data and plotted the noise histograms for channels 2,3 and 4, which you can find attached (without offset correction, named zero_peak_after_spike_removal_ch*.png). For completeness, we also attached the plot from ch1 (the sine wave). The selections in time and amplitude we applied had the goal to remove the high oscillations in amplitude occurring in the first and last samples and to discard the quadro spikes we had in the data.
We see that there is a peak at 0 mV in all histograms from all channels and scanning through the data, we saw that indeed the value 0 mV is stored many times for each event, thus originating the peak we see in the histograms. We also applied an offset correction to the data (taking the average of the first three most occuring amplitudes) of channels 2 (as an example) and the problem seems to be only partially removed.
We also noticed that this peak at 0 mV is present also when we acquired the data from the DRS4 with DRSosc saving the data in binary format.
So we had the following questions:
- why is the DRS4 saving so many times the value 0 mV (exactly 0 mV)?
- is there any way (in our case through software, preferably at acquisition time) to solve this problem?
Thank you for the help and best regards,
Alessio & Davide
|
|
|
|
|
|
Fri Feb 24 17:34:28 2017, Tarik Zengin, Passing parameters to drscl
|
Hi everyone,
I wonder if there is a way to pass parameters to drscl. What I specifically want to do is calling drscl from a shell script and read/save some data. I want to schedule a measurement. Therefore I need to call drscl from the command line using some parameters.
It would look something like this;
#!/bin/bash
for i in {0..100}
do
echo "Reading $i"
./drscl read 0 0 test.xml
sleep 1
done
This doesn't work of course. drscl won't take arguments from the command line. Can you suggest a way to do this please?
Thank you. |
Fri Feb 24 18:35:38 2017, Stefan Ritt, Passing parameters to drscl
|
This is indeed currently not implemented. But there is a simple C program drs_exam.cpp, which connects to a board and safes some data. You could modify that program to your needs.
Stefan
Tarik Zengin wrote: |
Hi everyone,
I wonder if there is a way to pass parameters to drscl. What I specifically want to do is calling drscl from a shell script and read/save some data. I want to schedule a measurement. Therefore I need to call drscl from the command line using some parameters.
It would look something like this;
#!/bin/bash
for i in {0..100}
do
echo "Reading $i"
./drscl read 0 0 test.xml
sleep 1
done
This doesn't work of course. drscl won't take arguments from the command line. Can you suggest a way to do this please?
Thank you.
|
|
Sat Feb 20 01:56:05 2010, Hao Huan, PLLLCK signal of DRS4
|
Hi Stefan,
in the latest DRS4 datasheet I only saw your data of the DRS4 PLL locking time for 6GSPS sampling speed, with other rows "TBD". Have you tried those lower frequencies? According to the datasheet I think the PLLLCK should be stabily low when the PLL is locked; am I right? However when I try my design with the DRS4 chip and feed the reference clock signal at 0.5MHz or 2MHz, the PLLLCK I get can never stabilize. There could be some problem in the PCB circuit connection, but I want to confirm with you since I'm confused with those "TBD" blanks.
Thanks a lot!
|
Sat Feb 20 09:54:48 2010, Stefan Ritt, PLLLCK signal of DRS4
|
Hao Huan wrote: |
Hi Stefan,
in the latest DRS4 datasheet I only saw your data of the DRS4 PLL locking time for 6GSPS sampling speed, with other rows "TBD". Have you tried those lower frequencies? According to the datasheet I think the PLLLCK should be stabily low when the PLL is locked; am I right? However when I try my design with the DRS4 chip and feed the reference clock signal at 0.5MHz or 2MHz, the PLLLCK I get can never stabilize. There could be some problem in the PCB circuit connection, but I want to confirm with you since I'm confused with those "TBD" blanks.
Thanks a lot!
|
The locking time is typically 20-30 cycles of the external reference clock, I will update the numbers in the datasheet soon. I attached a screenshot of the chip when starting up at 1 GHz (0.5 MHz REFCLK), so you can see the behaviour. The upper curver is the DTAP signal, the lower curve the PLLLCK signal. As you can see, the PLLLCK signal is not purely digital. Actually it's a simple XOR between the REFCLK and the DTAP signal, so you need an external 4.7nF capacitor to "integrate" this signal. Without this capacitor, you would see small negative spikes whenever there is s small phase shift between the DTAP and the REFCLK signal. Have a look at your DTAP signal, is it in phase with the REFCLK? |
Sun Feb 21 00:46:01 2010, Hao Huan, PLLLCK signal of DRS4
|
Stefan Ritt wrote: |
Hao Huan wrote: |
Hi Stefan,
in the latest DRS4 datasheet I only saw your data of the DRS4 PLL locking time for 6GSPS sampling speed, with other rows "TBD". Have you tried those lower frequencies? According to the datasheet I think the PLLLCK should be stabily low when the PLL is locked; am I right? However when I try my design with the DRS4 chip and feed the reference clock signal at 0.5MHz or 2MHz, the PLLLCK I get can never stabilize. There could be some problem in the PCB circuit connection, but I want to confirm with you since I'm confused with those "TBD" blanks.
Thanks a lot!
|
The locking time is typically 20-30 cycles of the external reference clock, I will update the numbers in the datasheet soon. I attached a screenshot of the chip when starting up at 1 GHz (0.5 MHz REFCLK), so you can see the behaviour. The upper curver is the DTAP signal, the lower curve the PLLLCK signal. As you can see, the PLLLCK signal is not purely digital. Actually it's a simple XOR between the REFCLK and the DTAP signal, so you need an external 4.7nF capacitor to "integrate" this signal. Without this capacitor, you would see small negative spikes whenever there is s small phase shift between the DTAP and the REFCLK signal. Have a look at your DTAP signal, is it in phase with the REFCLK?
|
Thanks! I see. The capacitor is important. However I'm a little confused... If PLLLCK=DTAP XOR REFCLK, shouldn't it integrate to low instead of high when the two clocks are in phase? I must have some misunderstanding here. So if we ignore any realistic complexity and assume DTAP is perfectly locked with REFCLK, will PLLLCK be always low or high? I'm sorry I do not know how the DRS internal PLL and its input/output work... |
Sun Feb 21 13:47:03 2010, Stefan Ritt, PLLLCK signal of DRS4
|
Hao Huan wrote: |
Thanks! I see. The capacitor is important. However I'm a little confused... If PLLLCK=DTAP XOR REFCLK, shouldn't it integrate to low instead of high when the two clocks are in phase? I must have some misunderstanding here. So if we ignore any realistic complexity and assume DTAP is perfectly locked with REFCLK, will PLLLCK be always low or high? I'm sorry I do not know how the DRS internal PLL and its input/output work...
|
Actually the XOR is followed by an inverter, so it will integrate to high if the two clocks are in phase. |
Sun Feb 21 20:27:46 2010, Hao Huan, PLLLCK signal of DRS4
|
Stefan Ritt wrote: |
Hao Huan wrote: |
Thanks! I see. The capacitor is important. However I'm a little confused... If PLLLCK=DTAP XOR REFCLK, shouldn't it integrate to low instead of high when the two clocks are in phase? I must have some misunderstanding here. So if we ignore any realistic complexity and assume DTAP is perfectly locked with REFCLK, will PLLLCK be always low or high? I'm sorry I do not know how the DRS internal PLL and its input/output work...
|
Actually the XOR is followed by an inverter, so it will integrate to high if the two clocks are in phase.
|
Got it. Thank you! By the way I have another question: when the default operation mode of the DRS4 chip is used, i.e. WSRIN is fed internally to WSROUT, at the external pins is it necessary to leave the WSRIN open? Or any input through the pin will not affect the Domino wave running? Also I observe that WSROUT will be always low when the chip is running in this mode; is it the supposed behavior? |
Sun Feb 21 20:33:57 2010, Stefan Ritt, PLLLCK signal of DRS4
|
Hao Huan wrote: |
By the way I have another question: when the default operation mode of the DRS4 chip is used, i.e. WSRIN is fed internally to WSROUT, at the external pins is it necessary to leave the WSRIN open? Or any input through the pin will not affect the Domino wave running? Also I observe that WSROUT will be always low when the chip is running in this mode; is it the supposed behavior?
|
If the WSRin is fed internally to WSROUT, then the level of the WSRIN pin does not matter, it's just disconnected. You can leave the pin open without problem. WSROUT is however active, so you can observe the internal state of the write shift register. In the default configuration (8x1024 sampling cells), all 8 channels are active all the time, so the WSR is loaded with ones. The inverter at the output then makes all zeros from this. If you configure the chip as 4x2048 cells, then you will observe switching bits at WSROUT. |
Mon Feb 22 17:23:59 2010, Hao Huan, PLLLCK signal of DRS4
|
Stefan Ritt wrote: |
Hao Huan wrote: |
By the way I have another question: when the default operation mode of the DRS4 chip is used, i.e. WSRIN is fed internally to WSROUT, at the external pins is it necessary to leave the WSRIN open? Or any input through the pin will not affect the Domino wave running? Also I observe that WSROUT will be always low when the chip is running in this mode; is it the supposed behavior?
|
If the WSRin is fed internally to WSROUT, then the level of the WSRIN pin does not matter, it's just disconnected. You can leave the pin open without problem. WSROUT is however active, so you can observe the internal state of the write shift register. In the default configuration (8x1024 sampling cells), all 8 channels are active all the time, so the WSR is loaded with ones. The inverter at the output then makes all zeros from this. If you configure the chip as 4x2048 cells, then you will observe switching bits at WSROUT.
|
Sorry; WSROUT also has an inverter? Actually I have one more stupid question about the shift registers: when we assert the address bits to operate on one shift register, e.g. WSR, we use SRIN to give input and SROUT to read output; but how does the shift register know whether we're reading or writing? Or it will just receive input from SRIN and give output at SROUT at the same time?
Thank you so much! |
Wed Mar 3 14:37:40 2010, Stefan Ritt, PLLLCK signal of DRS4
|
Hao Huan wrote: |
Stefan Ritt wrote: |
Hao Huan wrote: |
By the way I have another question: when the default operation mode of the DRS4 chip is used, i.e. WSRIN is fed internally to WSROUT, at the external pins is it necessary to leave the WSRIN open? Or any input through the pin will not affect the Domino wave running? Also I observe that WSROUT will be always low when the chip is running in this mode; is it the supposed behavior?
|
If the WSRin is fed internally to WSROUT, then the level of the WSRIN pin does not matter, it's just disconnected. You can leave the pin open without problem. WSROUT is however active, so you can observe the internal state of the write shift register. In the default configuration (8x1024 sampling cells), all 8 channels are active all the time, so the WSR is loaded with ones. The inverter at the output then makes all zeros from this. If you configure the chip as 4x2048 cells, then you will observe switching bits at WSROUT.
|
Sorry; WSROUT also has an inverter? Actually I have one more stupid question about the shift registers: when we assert the address bits to operate on one shift register, e.g. WSR, we use SRIN to give input and SROUT to read output; but how does the shift register know whether we're reading or writing? Or it will just receive input from SRIN and give output at SROUT at the same time?
|
Actually I double checked the schematics, WSROUT has NO inverter at the output. So the output should be always one in a 8x1024 channel configuration.
Concerning the read/write you are right. On each clock cycle, SRIN will be shifted into the first bit, and the last bit will be visible at SROUT. |
Thu Nov 24 00:40:38 2016, Alexey Lubinets, PLL did not lock
|
Hello, everybody!
I installed DRSosc and DRScl. Command line works normally (at least, it can "see" the board). But when I start the oscilloscope, I have an error: "PLLs did not lock on USB board #0, serial number #...". In Info section I can see the board type = 9 (and in the error message I have "USB board #0").
After that I have a warning: "Board on USB0 has invalid voltge calibration. Only raw data will be displayed". I tried to execute voltage calibration using DRSosc and DRScl, but it did not help.
Did anybody face such broblems? Does anybody know, how to fix them?
Thank you. Alexey. |
Thu Nov 24 08:13:23 2016, Stefan Ritt, PLL did not lock
|
Which serial number has the board? Has it been in use before or is it a new board?
Stefan
Alexey Lubinets wrote: |
Hello, everybody!
I installed DRSosc and DRScl. Command line works normally (at least, it can "see" the board). But when I start the oscilloscope, I have an error: "PLLs did not lock on USB board #0, serial number #...". In Info section I can see the board type = 9 (and in the error message I have "USB board #0").
After that I have a warning: "Board on USB0 has invalid voltge calibration. Only raw data will be displayed". I tried to execute voltage calibration using DRSosc and DRScl, but it did not help.
Did anybody face such broblems? Does anybody know, how to fix them?
Thank you. Alexey.
|
|
Mon Nov 28 16:48:15 2016, Alexey Lubinets, PLL did not lock
|
The serial number is 2586. This board is about two years old, and it might be in use (but I do not know exactly).
Stefan Ritt wrote: |
Which serial number has the board? Has it been in use before or is it a new board?
Stefan
Alexey Lubinets wrote: |
Hello, everybody!
I installed DRSosc and DRScl. Command line works normally (at least, it can "see" the board). But when I start the oscilloscope, I have an error: "PLLs did not lock on USB board #0, serial number #...". In Info section I can see the board type = 9 (and in the error message I have "USB board #0").
After that I have a warning: "Board on USB0 has invalid voltge calibration. Only raw data will be displayed". I tried to execute voltage calibration using DRSosc and DRScl, but it did not help.
Did anybody face such broblems? Does anybody know, how to fix them?
Thank you. Alexey.
|
|
|
Mon Nov 28 16:52:38 2016, Stefan Ritt, PLL did not lock
|
Have you tried to unplug and re-plug the board a few times? According to our database, you should have three boards. Do all three show the same behavior or only this board? In case all three show this, it could be a hint of a software problem. If two boards are good and one is bad, this would be a hint of a hardware problem (broken board).
Stefan
Alexey Lubinets wrote: |
The serial number is 2586. This board is about two years old, and it might be in use (but I do not know exactly).
Stefan Ritt wrote: |
Which serial number has the board? Has it been in use before or is it a new board?
Stefan
Alexey Lubinets wrote: |
Hello, everybody!
I installed DRSosc and DRScl. Command line works normally (at least, it can "see" the board). But when I start the oscilloscope, I have an error: "PLLs did not lock on USB board #0, serial number #...". In Info section I can see the board type = 9 (and in the error message I have "USB board #0").
After that I have a warning: "Board on USB0 has invalid voltge calibration. Only raw data will be displayed". I tried to execute voltage calibration using DRSosc and DRScl, but it did not help.
Did anybody face such broblems? Does anybody know, how to fix them?
Thank you. Alexey.
|
|
|
|
Sun Mar 21 02:03:44 2010, Hao Huan, PLL Loop Filter Configuration
|
Hi Stefan,
in the datasheet it says at 6GSPS the typical loop filter parameters are 220Ω, 2.2nF and 27nF. If I want to run the Domino wave nominally at 1GHz, i.e. with a reference clock frequency around 0.5MHz, is there any recommended loop filter configuration? Is the setup of the evaluation board, that is, 220Ω, 3.3nF and 33nF an optimal choice?
Thank you very much.
|
Mon Mar 22 09:12:19 2010, Stefan Ritt, PLL Loop Filter Configuration
|
Hao Huan wrote: |
in the datasheet it says at 6GSPS the typical loop filter parameters are 220Ω, 2.2nF and 27nF. If I want to run the Domino wave nominally at 1GHz, i.e. with a reference clock frequency around 0.5MHz, is there any recommended loop filter configuration? Is the setup of the evaluation board, that is, 220Ω, 3.3nF and 33nF an optimal choice?
|
The setup of the evaluation board is a good compromise which runs between 1 GHz and 5 GHz. Unfortunately I never found the time to investigate this in more detail. So if someone is willing to measure settling time and phase jitter with various combinations of R, C1 and C2, I'm more than happy to include this into the datasheet. |
|