DRS4 Forum
  DRS4 Discussion Forum, Page 11 of 45  Not logged in ELOG logo
ID Datedown Author Subject
  703   Tue Jun 19 06:42:23 2018 Phan Van ChuanThe data acquisition speed

Dear Stefan,

We are using an DRS4 board V5.1 for building a metering system for the scintillator detector by a Labview program. The program was built based on the functions in DRS.cpp and it reads data from channel 0 very well (Fig 1). Now, I am having a problem with the data acquisition from DRS4 board. The data acquisition speed on this program is only about 30-50 Acq / s, while using the DRS Oscilloscope that of about 300-400 Acq / s.

When the program was installed with fDominoMode = 0 and fDominoActive = 0, the data acquisition speed was about 300-400 Acq / s. However, the waveform is inaccurate.

I do not know if I installed the wrong function! Can you show me how to solve this problem?

In the Labview program, functions (corresponding to functions in DRS.cpp) are called with the following parameters:

 

InitFPGA();

SetMultiBuffer(0);

fROFS = 1.6;              // differential input range -0.5V ... +0.5V

fRange = 0;

SetDAC(fDAC_ROFS_1, fROFS);

 fCommonMode = 0.8;        // 0.8V +- 0.5V inside NMOS range

SetDAC(fDAC_CALP, fCommonMode);

SetDAC(fDAC_CALN, fCommonMode);

SetDAC(fDAC_BIAS, 0.70);

/* set default number of channels per chip */

SetChannelConfig(0, fNumberOfReadoutChannels - 1, 8);

// set ADC clock phase

      fADCClkPhase = 0;

      fADCClkInvert = 0;

   // default settings

fMultiBuffer = 0;

   fNMultiBuffer = 0;

   fDominoMode = 1;

   fReadoutMode = 1;

   fReadPointer = 0;

   fTriggerEnable1 = 1;

   fTriggerEnable2 = 0;

   fTriggerSource = 0;

   fTriggerDelay = 0;

   fTriggerDelayNs = 0;

   fSyncDelay = 0;

   fNominalFrequency = 1;

   fDominoActive = 1;

// load calibration from EEPROM

ReadCalibration();

...

SetDominoMode(fDominoMode);

   SetReadoutMode(fReadoutMode);

   EnableTrigger(fTriggerEnable1, fTriggerEnable2);

   SetTriggerSource(fTriggerSource);

   SetTriggerDelayPercent(0);

   SetSyncDelay(fSyncDelay);

   SetDominoActive(fDominoActive);

   SetFrequency(fNominalFrequency, true);

   SetInputRange(fRange);

SelectClockSource(0); // FPGA clock

// disable calibration signals

   EnableAcal(0, 0);

   SetCalibTiming(0, 0);

   EnableTcal(0);

   // got to idle state

   Reinit();

 

////////

SetFrequency (1,false);

settranspmode (1);

setinputrange(0);

EnableTcal (0,-,-);

EnableTrigger(1, 0);

SetTriggerSource(0);

SetTriggerLevel(0);

SetTriggerPolarity(false);

SetTriggerDelayNs(512);

 

// in loop of read data from DRS4:

 {

StartDomino();

while (b->IsBusy());

TransferWaves(0, 8);

GetTime(0, 0, b->GetTriggerCell(0), time_array[0]);

GetWave(0, 0, wave_array[0]);

}

 

Thank you very much!

Best Regards,

Chuan

 

 

  702   Wed Jun 13 16:34:28 2018 Julian KempMaximum analog input voltage

Thank you! That solves my problem.

Stefan Ritt wrote:

In principle the numbers in the manual are correct. But they relate to pulses of a certain length, because the input protection only works for DC voltage and for pulses which are not too long. Since we could not write this all on the label of the board, we decided to put there 100% safe value as a "warning" to people, meaning that if pulses are above 2.5V, they should look into the manual and read the details. 

Stefan

Julian Kemp wrote:

Dear all,

I have been wondering what the maximum analog input voltage for the DRS4 V5 evaluation board is. It came with a sticker indicating that it is "2.5V pk Max". On the other hand, when checking the manual (https://www.psi.ch/drs/DocumentationEN/manual_rev50.pdf), it says maximum allowed is 10V DC or even 30V for short pulses. I foresee an application where I cannot make sure that pulses stay below 2.5V, so the correct value will be quite important for me.

Best,
Julian

 

 

  701   Wed Jun 13 13:42:47 2018 Stefan RittMaximum analog input voltage

In principle the numbers in the manual are correct. But they relate to pulses of a certain length, because the input protection only works for DC voltage and for pulses which are not too long. Since we could not write this all on the label of the board, we decided to put there 100% safe value as a "warning" to people, meaning that if pulses are above 2.5V, they should look into the manual and read the details. 

Stefan

Julian Kemp wrote:

Dear all,

I have been wondering what the maximum analog input voltage for the DRS4 V5 evaluation board is. It came with a sticker indicating that it is "2.5V pk Max". On the other hand, when checking the manual (https://www.psi.ch/drs/DocumentationEN/manual_rev50.pdf), it says maximum allowed is 10V DC or even 30V for short pulses. I foresee an application where I cannot make sure that pulses stay below 2.5V, so the correct value will be quite important for me.

Best,
Julian

 

  700   Wed Jun 13 13:23:17 2018 Julian KempMaximum analog input voltage

Dear all,

I have been wondering what the maximum analog input voltage for the DRS4 V5 evaluation board is. It came with a sticker indicating that it is "2.5V pk Max". On the other hand, when checking the manual (https://www.psi.ch/drs/DocumentationEN/manual_rev50.pdf), it says maximum allowed is 10V DC or even 30V for short pulses. I foresee an application where I cannot make sure that pulses stay below 2.5V, so the correct value will be quite important for me.

Best,
Julian

  699   Fri Jun 8 08:11:05 2018 Stefan Ritt 

Several people reported this problem, but we cannot reproduce it at our lab. Both the oscilloscope and the command line interface use exactly the same code to connect to the board. Have you tried the solution reported here: elog:657 ?

Best,

Stefan

Phan Van Chuan wrote:

Dear Stefan,

I am using an DRS4 board to test the signal from an scintillator detector; It has connected well to the computer on DRS Oscilloscope (Figure 1). Now, I am having a problem of developing from the code of the drs_exam program, because the DRS4 board has not connected to the computer when translation the drs_exam program (Figure 2). Before running the drs_exam program, I copied the libusb-1.0.lib file to the computer's "C: \ Program Files \ Microsoft SDKs \ Windows \ v7.0A \ Lib" folder. Can you show me how to solve this problem?

 

Figure 1.

 

Figure 2.

Thank you very much!

Best Regards,

Chuan

 

  698   Thu Jun 7 16:27:21 2018 Phan Van Chuan 

Dear Stefan,

I am using an DRS4 board to test the signal from an scintillator detector; It has connected well to the computer on DRS Oscilloscope (Figure 1). Now, I am having a problem of developing from the code of the drs_exam program, because the DRS4 board has not connected to the computer when translation the drs_exam program (Figure 2). Before running the drs_exam program, I copied the libusb-1.0.lib file to the computer's "C: \ Program Files \ Microsoft SDKs \ Windows \ v7.0A \ Lib" folder. Can you show me how to solve this problem?

 

Figure 1.

 

Figure 2.

Thank you very much!

Best Regards,

Chuan

  697   Thu May 17 13:29:34 2018 Stefan Ritt"Symmetric spikes" fixed

Good news for all DRS4 users. After many years, I finally understand where the "symmetric spikes" come from and how to fix them.

The "symmetric spikes" are small spikes of 17-18mV, which randomly happen at 1-2 cells. They alwas come in groups of 2 in each channel, symmetric around sampling cell #512. See first attachment.

The reason for the spikes is the previous readout cycle. On each readout cycle, the "read bit" is clocked through all 1024 cells to switch one cell contents to the DRS4 output. At the end of the 1024 cycles, the read bit stays at its last position. The bit is carried by a metal line on the chip, which crosses all 9 channels (second attachment). This bit now influences the sampling cells below the metal line capacitively, so their contents is "pushed up" by a few mV, just like the ROFS offset does. Since the DRS sampling channels are in a snake layout, going 0-512 from left, then 512-1023 back again, the line crosses two cells in each channel, and thus the symmetric spikes.

Previously, there was a software solution for that. In the evaluation board software DRSOsc there is a button "Remove spikes" which tries to fix this in software. Although this works most of the time, it's annoying and not 100% safe. Like when the spike sits on top of a noise signal, it might not be recognized. Fixing this in hardware is however straight forwar. After the readout cycle ends, push the read bit out of the chip:

  • Address the read shift register by applying 1011b to A3:A0
  • Switch SRIN low
  • Apply 1024 clock cycles to SRCLK

This shifts the bit out of the chip, so that the next event is not affected by the read bit. The third attachment show the effect of this. The "clear cycle" increases the readout time a little bit, but depending on the application this might be worth it.

Regards,
Stefan

  696   Mon May 14 09:21:29 2018 Alessio BertiWIndows Connection problem with drs507 SOLVED

Hi,

I have a machine with Windows 10 and the solution provided by Steven works fine. To give more details, the driver installed in my case is WinUSB (i.e. libusb, v6.1.7600.16385).

Cheers,

Alessio

Alec Shackleford wrote:

Thank you for this fantastic solution. I had almost reinstalled windows 7 to see if that would solve the issue!

 

All the best,

Alec

Stefan Ritt wrote:

Dear Steven, many thanks for this information, this is very useful. I know of people having problems on Windows 10, maybe this will also help them.

Stefan

Steven Block wrote:

Hello All,

I too have been struggling with trying to get the drs4 (507) to work on my windows machine and I found it to be a problem with the libusb library. My solution is as follows and has worked on multiple PC's. I ran this solution after I first plugged in the drs4 and installed 507.

Go to http://zadig.akeo.ie/ and install the corresponding software.

After that, you will need to plug in the DRS4 to your computer. From there go to ‘Options’, and select ‘List all Devices’.

Finally, choose the DRS4 evaluation board from the list and press install driver and let it run. You should be fine after that. 

Best,

Steven

 

 

 

  695   Wed May 9 14:07:10 2018 Alec ShacklefordWIndows Connection problem with drs507 SOLVED

Thank you for this fantastic solution. I had almost reinstalled windows 7 to see if that would solve the issue!

 

All the best,

Alec

Stefan Ritt wrote:

Dear Steven, many thanks for this information, this is very useful. I know of people having problems on Windows 10, maybe this will also help them.

Stefan

Steven Block wrote:

Hello All,

I too have been struggling with trying to get the drs4 (507) to work on my windows machine and I found it to be a problem with the libusb library. My solution is as follows and has worked on multiple PC's. I ran this solution after I first plugged in the drs4 and installed 507.

Go to http://zadig.akeo.ie/ and install the corresponding software.

After that, you will need to plug in the DRS4 to your computer. From there go to ‘Options’, and select ‘List all Devices’.

Finally, choose the DRS4 evaluation board from the list and press install driver and let it run. You should be fine after that. 

Best,

Steven

 

 

  694   Wed May 9 09:03:52 2018 Stefan RittManual Rev5.1 Figure 1, optional components

I updated the picture in the manual with a current picture of a Rev5.1 board, and also added a picture of the bottom side. If you need a picture without the blue labels, have a look at https://www.psi.ch/drs/old-evaluation-boards at the bottom.

Here is the explanation of the optional components:

- R1, C2, R6, R29, R30 and same components for other channels: Normally the board is AC-coupled. You can make the board DC-coupled by briding C1, C9, C13, removing R6, C2, adding R1, adding R29, removing R30. The CAL signal then enters before the THS4508. We found that DC coupling gives slightly higher noise and is prone to high input DC levels, so we ship the board usually AC-coupled.

- R84 & Co. defines the hysteresis of the trigger comparators as described in the schematics

- R99-R106, R143: If soldered, the board is configured in cascading mode with 4 channels @ 2048 bins. R143 tells the FPGA that we are in this mode, so the firmware can correctly configure the DRS4

- R118 & Co. defines the MCX output level to be either 3.3V or 5V (default)

- R146-R149 connect JTAG to the uC. We planned at one point to make firmware upgrades through USB, but we never implemented that, so these resistors are not soldered.

I hope I covered everything. If I overlooked any optional component please tell me.

Cheers,
Stefan

Sean Quinn wrote:

Dear All,

 

I'm troubleshooting a board which uses the DRS4 and adopts an analog front end very similar to the evaluation board. As a result, we rely on the eval board as a reference. In doing so we've encountered an issue in the manual:

The high resolution photo in Figure 1. is useful, but it seems to correspond to an older version of the board. For instance, the RF switch can't correspond to the schematics of Rev5.1 in the appendix.

Request: Could the manual be updated with a high resolution image of Rev5.1. Also, could a high resolution of the bottom side of the board be included in the manual? This is desirable since it has the version number and contact information, so it will remove any ambiguity about what board you're looking at and what schematics you should refer to.

A second question, which might be overly broad: what is the impact of installing the optional components (marked * in the schematics) on the analog front end? Why are a lot of these left uninstalled on the eval board?

Thanks,

Sean

 

  693   Tue May 8 23:58:35 2018 Sean QuinnManual Rev5.1 Figure 1, optional components

Dear All,

 

I'm troubleshooting a board which uses the DRS4 and adopts an analog front end very similar to the evaluation board. As a result, we rely on the eval board as a reference. In doing so we've encountered an issue in the manual:

The high resolution photo in Figure 1. is useful, but it seems to correspond to an older version of the board. For instance, the RF switch can't correspond to the schematics of Rev5.1 in the appendix.

Request: Could the manual be updated with a high resolution image of Rev5.1. Also, could a high resolution of the bottom side of the board be included in the manual? This is desirable since it has the version number and contact information, so it will remove any ambiguity about what board you're looking at and what schematics you should refer to.

A second question, which might be overly broad: what is the impact of installing the optional components (marked * in the schematics) on the analog front end? Why are a lot of these left uninstalled on the eval board?

Thanks,

Sean

  692   Tue May 8 14:43:03 2018 Stefan RittPeak 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

 

 

 

 

 

 

  691   Tue May 8 12:15:54 2018 Alessio BertiPeak 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

 

 

 

 

 

  690   Sun May 6 11:45:09 2018 Stefan Rittconfusion about the description in drs.cpp

The locbus_addr is indeed 32 bits wide, since the firmware was originally derived from some firmware running in a VME crate, and the VME bus has 32 bits or addressing. So you will still find some "historic" remnants from that era. In the USB firmware, lcobus_addr[32:8] is always zero. Sorry for the confusuion.

Stefan

chen wenjun wrote:

Hi Stefan:

  I'm still confused that althought the 8 bits buffer is enough,the FPGA receive the command through the uc_data_i register which is 16 bits wides.As we can see in the firmware, the locbus_addr is 32 bits wides. Does it means the locbus_addr[31:8] are always '0' because the address in buffer is only 8 bits. Does it means the usrbus_status_sel and usrbus_ram_sel are also '0' all the time .

thanks!

chen

Stefan Ritt wrote:

The FPGA is very small, so it only has an address space of 256 bytes. Look at the definition in DRS.cpp

#define USB_CTRL_OFFSET                 0x00    /* all registers 32 bit */
#define USB_STATUS_OFFSET               0x40
#define USB_RAM_OFFSET                  0x80

The registers are 32 bits wide, but the addresses only run from 0 to 255, and thus a single byte is enough for addressing them.

chen wenjun wrote:

Hi,Stefan:

  recently,whtn I study the drs.cpp code ,I found that  the buffer[1] is char but the addr and the base_addr are all unsigned int,isn't there any problem that the addr may be cut off to 8 bits? Also ,I found that the data fpga recieved from the usb is 16 bits,so how can fpga get the true 32bits address from the PC.

 

 

 

  689   Sun May 6 08:13:37 2018 chen wenjunconfusion about the description in drs.cpp

Hi Stefan:

  I'm still confused that althought the 8 bits buffer is enough,the FPGA receive the command through the uc_data_i register which is 16 bits wides.As we can see in the firmware, the locbus_addr is 32 bits wides. Does it means the locbus_addr[31:8] are always '0' because the address in buffer is only 8 bits. Does it means the usrbus_status_sel and usrbus_ram_sel are also '0' all the time .

thanks!

chen

Stefan Ritt wrote:

The FPGA is very small, so it only has an address space of 256 bytes. Look at the definition in DRS.cpp

#define USB_CTRL_OFFSET                 0x00    /* all registers 32 bit */
#define USB_STATUS_OFFSET               0x40
#define USB_RAM_OFFSET                  0x80

The registers are 32 bits wide, but the addresses only run from 0 to 255, and thus a single byte is enough for addressing them.

chen wenjun wrote:

Hi,Stefan:

  recently,whtn I study the drs.cpp code ,I found that  the buffer[1] is char but the addr and the base_addr are all unsigned int,isn't there any problem that the addr may be cut off to 8 bits? Also ,I found that the data fpga recieved from the usb is 16 bits,so how can fpga get the true 32bits address from the PC.

 

 

  688   Fri May 4 12:11:57 2018 Stefan RittRunning drs_example.cpp

And here is the second part of your answer: When you change the input range, you have to redo the voltage calibration. Best is if you do that in the DRSOsc program, then you see that it's working. Then start your custom program and use the same range.

Stefan

Rodrigo Trindade de Menezes wrote:

We found a way to solve the previous problem, but right now when we try to set the input range only -0.5 to 0.5 is working. When we set the function "SetInputRange(0.5)" for 0 to 1V the output is all zeros and with  "SetInputRange(0.45)" we just get all the outputs -49.9mV. What does that means? How to fix?

odrigo Trindade de Menezes wrote:

Hello,

We have been using the DRS4 evaluation board (S/N 2636) that works with the scope application. However we are trying to run the DRS4 evaluation board remotely by modifying the drs_exam.cpp to acquire and store data continuously.

We compiled the DRS_example.cpp without the wxWidgets but when we try to run the program, it appears to trigger on nonsense.  The program appears to not be sensitive to the trigger threshold (although for very large trigger threshold it gets stuck in a waiting mode).  Is there a way to ensure that the "normal" trigger mode is set?  We are worried that the auto mode is running.  Otherwise, not sure why the program is triggering on nonsense.  By the way, it does not work with the wxWidgets compiled either so we are worried that there is an additional flag that needs to be set. The routine does not appear to conduct a calibration -- is this not necessary?

Another issue that we are having is with the data set stored on the .txt file looks incorrect.  The time channel stops at 200 (but we think it should go up to 1024). In addition, the voltage channel appears to hover around small values near zero (as if triggering on noise).  The output file appears this way even when we change the threshold to much higher values.  It suggests that the trigger threshold is not actually being set? There are events where the output voltage appears to oscillate through huge negative and positive values too.  So not sure what's going on. 

Thanks!

Rodrigo

 

 

  687   Fri May 4 11:56:08 2018 Stefan RittVoltage and Timing Calibration in drs_exam.cpp

Have you set the sampling frequency 

b->SetFrequency(5, true);

before the calibration?

Note there is also the "drscl" program, which is a ocmmand linke interface to the evaluation board. Start it, and do the calibration there:

/drs4eb/software/drscl$ ./drscl
DRS command line tool, Revision 21435
Type 'help' for a list of available commands.

Found DRS4 board  0 on USB, serial #2400, firmware revision 30000
B0> freq 5
B0> calib
           Enter calibration frequency [GHz]: 5
                             Enter range [V]: 0
        Enter mode [1]024 or [2]048 bin mode: 1

Please make sure that no input signal are present then hit any key
Creating Calibration of Board on USB, serial #2400                
B0> ===============================================]
B0> 

then look at the code in drscl.cpp (around line 1097).

/Stefan

Alessio Berti wrote:

Hi,

we were trying to implement an automatic way to calibrate our DRS4 both in voltage and in time (we have the V5 Evaluation Board). We started from drs_exam.cpp and tried with the following lines:

/* set input range to -0.5V ... +0.5V */

b->SetInputRange(0);

b->CalibrateVolt(NULL);
b->CalibrateTiming(NULL);

While the timing calibration seems to work (we checked with drsosc executable), the voltage calibration in our test program seems not to do the same as in drsosc when pressing the button "Execute Voltage Calibration". Specifically we think that no primary calibration, secondary calibration or spike removal is applied when calling CalibrateVolt(). It seems that the methods to perform those tasks are implemented in Osci.ccp/Osci.h, but drs_exam.cpp uses objects of the class DRS (i.e. defined in DRS.cpp and DRS.h).

Is there a way to execute the voltage calibration in drs_exam.cpp in the same way performed within drsosc?

Cheers,

Alessio

 

  686   Fri May 4 11:35:20 2018 Stefan RittPeak 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

 

 

 

 

  685   Wed May 2 12:23:16 2018 Alessio BertiPeak 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

 

 

 

  684   Wed May 2 12:12:42 2018 Stefan RittPeak at 0 mV in traces

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

 

 

ELOG V3.1.5-fe60aaf