Yes, but you have to recompile the oscilloscope application. Find following line in the source file DOFrame.cpp:

            m_WFfd = open(filename.char_str(), O_RDWR | O_CREAT | O_TRUNC | O_TEXT, 0644);

and replace it with

            m_WFfd = open(filename.char_str(), O_RDWR | O_CREAT | O_TRUNC | O_BINARY, 0644);

 that fixes the problem. To compile the program, you need MS Visual C++ and you have to install the vxWidgets library. Let me know if you have any problem with that.

Anyhow I plan a major software update soon (weeks), which not only fixes this problem, but also reduces the noise considerably by doing a kind of two-fold calibration.

- Stefan

Hello again. I have not got evaluation board yet, but already faced some difficulties:) I'm trying to compile drs_exam.cpp on Windows 7 using dev-c++ with imagelib-2 and WxWindows 2.4.2 DevPaks installed, but nothing works. Compile log is attached. Honestly, I'm not very familiar with c++, so any suggestions will be helpful. Thank you.

I have no experience with dev-c++, so I cannot be of help here. The supported systems are Linux and Windows with MS Visual C++. But it looks like the problems are related to compiling wxWidgets, which actually you do NOT need for drs_exam.cpp. The wxWidgets library is only needed for the DRSOsc application. If you want to compile it anyhow, first learn how to compile standard WxWidgets applications from

http://www.wxwidgets.org/docs/tutorials/devcpp.htm

Best regards,

Stefan 

Ok, this was my bad, I added some unnecessary files to project. Drs_exam compiles well with ms vc++. Thanks!

Hi

 I can't download the software for windows on this website 'www.psi.ch/drs/software-download', there is some mistake when i click on download. 

 If convenient, can you send the software Version 5.0.5 for windows to me? My E-mail address is 'yuhaiyang421@163.com'. Thank you!

Best Regards

Yu

Can you tell me (screendump) what is the problem on the web site https://www.psi.ch/drs/software-download ? It should redirect you to

https://www.dropbox.com/sh/qul1cgtm4x7zx13/AADKQ-qGQGdAHPu6OR3vTNY0a?dl=0

for the Windows download.

I cannot send executables via email, that won't go though any spam filter.

Stefan

Maybe some of you have experienced that the DRS4 chip can get pretty hot after power up. After it's initialized the first time, the power consumption goes back to normal. I finally found the cause of this problem and have a remedy. Here is the new paragraph from the updated data sheet:

During power-up, care has to be taken that the DENABLE and DWRITE signals are low. If not, the domino wave can get started before the power supply voltages are stable, which brings the DRS4 chip into a state where it draws a considerable amount of current and heats up significantly. This can be problematic if the signals are directly generated by a FPGA, since most FPGAs have internal pull-up resistors which get activated during the configuration phase of the FPGA. In such a case, the DENABLE and DWRITE signals should be connected to GND with a pull down resistor. This resistor should be much smaller than the FPGA pull-up resistor in order to keep the signals close to GND during the FPGA configuration. A typical value is 4.7 kOhm.

The attached schematics shows the location of the two required resistors.

Hello,

I was running through a particular binary file containing data taken on all 4 channels of the DRS4 and printing out the value of the first time sample for each channel (per event). While doing so, I noticed that some of these times were negative. For this dataset, channel 1 was chosen as the reference channel (which is the default setup in Stefan's DRS4 macro).  From my understanding, the calibration procedure delineated in the DRS4 manual and shown in the code below is supposed to sync the timing of each channel relative to sample 0. However, this does not appear to be the case for when I print out the time value of the first sample, I notice that only channel 1's 0th sample is set to 0. The first sample for the other channels is nonzero (and most often negative). 

Even more strange is when I test another 4-channel dataset with the same code, this issue does not appear. More specifically, the first time sample on each waveform on all channels is set to 0, as should be the case.

My question is therefore whether or not the timing calibration varies from dataset to dataset. My initial thought was that this should not be the case, but I have two different data sets taken on the same set of channels which give different timing calibration results. Are there any circumstances under which this behavior can happen? 

for (ch=0 ; ch<5 ; ch++) {
         i = fread(hdr, sizeof(hdr), 1, f);
         if (i < 1)
            break;
         if (hdr[0] != 'C') {
            // event header found
            fseek(f, -4, SEEK_CUR);
            break;      
         }
         chn_index = hdr[3] - '0' - 1;
         fread(voltage, sizeof(short), 1024, f);
         
         for (i=0 ; i<1024 ; i++) {
            // convert data to volts
            waveform[chn_index][i] = (voltage[i] / 65536. - 0.5);
            
            // calculate time for this cell
            for (j=0,time[chn_index][i]=0 ; j<i ; j++)
              time[chn_index][i] += bin_width[chn_index][(j+eh.trigger_cell) % 1024];            
         }
      }
    
      // align cell #0 of all channels
      t1 = time[0][(1024-eh.trigger_cell) % 1024];
      for (ch=1 ; ch<4 ; ch++) {
         t2 = time[ch][(1024-eh.trigger_cell) % 1024];
         dt = t1 - t2;
         for (i=0 ; i<1024 ; i++)
            time[ch][i] += dt;
      }

The code in the macro is correct. The misconception lies in the definition what "sample 0" means. Please view the attached picture. This is simplified case with a DRS chip with only 8 cells (instead of 1024). There are two events (blue and red). In the first event, the chip is stopped at trigger cell (tc) 2, in the second case at 5. Since the readout starts with the trigger cell, the first readout sample in the first event belongs to cell #2, the next one to cell #3 and so on. In the second (red) case, the first sample belongs to cell #5, the second to cell #6 and so on. "Aligning cells 0" now means that the physical cell 0 (not the readout sample) is aligned for each channel. In the first event, the 7th readout sample will have the same time in all channels, in the second event the fourth readout cells will have the same time. This is because physical cell #0 is always at different places inside the readout array.

Stefan

for (ch=0 ; ch<5 ; ch++) {
         i = fread(hdr, sizeof(hdr), 1, f);
         if (i < 1)
            break;
         if (hdr[0] != 'C') {
            // event header found
            fseek(f, -4, SEEK_CUR);
            break;      
         }
         chn_index = hdr[3] - '0' - 1;
         fread(voltage, sizeof(short), 1024, f);
         
         for (i=0 ; i<1024 ; i++) {
            // convert data to volts
            waveform[chn_index][i] = (voltage[i] / 65536. - 0.5);
            
            // calculate time for this cell
            for (j=0,time[chn_index][i]=0 ; j<i ; j++)
              time[chn_index][i] += bin_width[chn_index][(j+eh.trigger_cell) % 1024];            
         }
      }
    
      // align cell #0 of all channels
      t1 = time[0][(1024-eh.trigger_cell) % 1024];
      for (ch=1 ; ch<4 ; ch++) {
         t2 = time[ch][(1024-eh.trigger_cell) % 1024];
         dt = t1 - t2;
         for (i=0 ; i<1024 ; i++)
            time[ch][i] += dt;
      }

Hello Stefan,

Thank you for the excellent explanation and diagram. This part of the code is now much clearer to me.

My other questions pertain to the "trigger cell". Firstly, what precisely does this mean? Moreover, how does the "trigger cell" relate to the trigger time delay we can set in the DRS4 application? This is causing some confusion for me, because regardless of where you set the trigger time delay on the DRS4 application, there are still points on the waveform that are saved prior to the moment in time when a pulse exceeds some voltage threshold we set in the application. I get the impression that "trigger delay" and "trigger cell" are unrelated concepts, so any clarification you can provide would be greatly appreciated.

Abhishek

for (ch=0 ; ch<5 ; ch++) {
         i = fread(hdr, sizeof(hdr), 1, f);
         if (i < 1)
            break;
         if (hdr[0] != 'C') {
            // event header found
            fseek(f, -4, SEEK_CUR);
            break;      
         }
         chn_index = hdr[3] - '0' - 1;
         fread(voltage, sizeof(short), 1024, f);
         
         for (i=0 ; i<1024 ; i++) {
            // convert data to volts
            waveform[chn_index][i] = (voltage[i] / 65536. - 0.5);
            
            // calculate time for this cell
            for (j=0,time[chn_index][i]=0 ; j<i ; j++)
              time[chn_index][i] += bin_width[chn_index][(j+eh.trigger_cell) % 1024];            
         }
      }
    
      // align cell #0 of all channels
      t1 = time[0][(1024-eh.trigger_cell) % 1024];
      for (ch=1 ; ch<4 ; ch++) {
         t2 = time[ch][(1024-eh.trigger_cell) % 1024];
         dt = t1 - t2;
         for (i=0 ; i<1024 ; i++)
            time[ch][i] += dt;
      }

The inverter chain in the DRS4 is continously running in a ring. Once you get a trigger, it is stopped. This happens in any of the 1024 cells. The last cell which sampled a signal plus ne is called "trigger cell". In the previous diagram in event #1, the last cell sampling was "1", so the trigger cell is "2". In event 2 (red case), the trigger cell is 5. If you would run like this, you see only the part of the waveform BEFORE your trigger (since the DRS4 is continously sampling and is stopped with the trigger). In order to see the full peak of your waveform, you can apply some external trigger to shift the trigger position to the right. This is done in the FPGA reading out the DRS4 chip. If your peak is let's say 20 ns wide, and you delay your trigger by 30 ns, you see the peak plus 10 ns right of the peak.

Stefan

Hello Stefan,

Many thanks for the explanations. You've cleared my confusion in this matter.  

Abhishek Rajput

Dear DRS4 team,

I am curious about this part of the circuit:

What is the purpose of this?

The attenuator compensates for the gain of the buffer which is slightly above one. In addition, it serves as a "placeholder" in case one wants larger input signals. One can easily convert the attenuator to -6db, -12db, etc. by chaning the resistors.

Stefan

Dear Dr. Ritt,

    In the DRS 4 datasheet it is recommended to sample the analog output of the chip after 8~10 ns of the SRCLK edge for it to stablize and thus a phase shift between SRCLK and the ADC sampling clock is necessary. However in the latest version of the evaluation board firmware the phase-shifted clock was generated but not really used for the ADC interface. Is there any reason for that?

Good questions. I looked myself in the code and found:

  drs_readout_clk       <= I_CLK33;

  drs_readout_clk_ps    <= I_CLK33; -- phase shifted clock for FADC

  drs_serial_clk        <= I_CLK33;

which is apparently wrong (should be drs_readout_clk_ps <= I_CLK33_PS;) . But apparently the board is working with the unshifted clock. Could be that the PCB traces to the DRS and the ADC have different lengths, and by accident, they have just the right value.

The way to find that out is to keep the ADC clock phase variable (most FPGAs allow a +-5 ns phase adjustment inside their clock blocks), and then try different values. If the phase shift is wrong, you will see spikes every 32 samples in the readout. The spikes are always there (from some internal switching of bus segments), and you can see them with a differential probe at the DRS output. The ADC phase must then be made such that the sampling point of the ADC comes after that spike, just at the end of the settling time, barely before the next analog value shows up at the DRS output. This is a bit tricky and can be made best just by trying out different values.

Hi -

I am setting up a new DRS4 rev5 but using drivers and software we were recently using with a Rev4 (with a recent release of the drs4 code, from mid-2014). 

I am writing since I see peculiar behavior of the calibrated times when I read them back from the Rev 5.  I get events where the first time returns 0 (which was always the case on my Rev 4), but the following time is negative -- this seems to be wrong since the times should always increase.

Is it a problem with my running the time calibration or a problem with the board itself?  For the record, the integral nonlinearity displayed during time calibration "looks" very different when running with the same (recent) drsosc on the two boards.  The rev5 has apparently a much larger amplitude.

- peter

First of all, you should not use new boards with old software. I try to keep the current software compatible with old boards, but not vice versa. Please use the DRS.cpp library from the current V5 software, otherwise your time calibration will not work.

If you then do the calibration with the V5 software and the V5 board, you will see that the bin widhts of the DRS chips are not the same. Actually they are "oscillating" between ~130 ps and ~270 ps if you run at 5 GSPS. Some bins are even negative, this means that the next bin sees the signal before the previous bin. This is correct and due to the specific layout of the chip which is not perfect. Using the new time calibration with the current software, you should be able to make time measurements with a few ps accuracy.

Stefan

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

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