Yes you do. But if you have WSRLOOP=1 in the config register, this is done automatically. So the SR output is visible at the pin and will be fed back into the input.

That's not correct. Have a look at Figure 14 of the datasheet. Do you see a single RSRLOAD pulse or many? There is only one RSRLOAD pulse to initialize the readout shift register, then the cells are clocked by SRCLK pulses. 

A single RSRLOAD pulse loads the RSR with a "1" at the domino stop position and "0" in all other places. A pulse on SRCLK shifts this "1" down the RSR. When it arrives at cell #1023, it will be visible for one clock cycle at WSROUT. The "double" functionality of WSROUT has the following background: Assume you use channel cascading 2x2048. Now the domino wave stopps in cell 1020 of the first channel for example. You have to read cells 1020,1021,1022,1024 of the first channel, then you continue with 0,1,2 on the second channel. But how do you know that you have to switch channels after the first four clock cycles? The SROUT output encodes the stop position (in this case 1020), but it needs 10 clock cycles before the information is available, so you don't have it after four cycles. That's where WSROUT comes into play: Since it outputs RSR bit by bit, it will show three "0", then a "1", when you are at cell 1023. Then you know that you have to switch channels immediately. That's why I output RSR via WSROUT if DWRITE is low.

Helo
I'm building an application for reading waveforms from the DRS4 board to PC. However, I am having problems reading calibration data from EEPROM on DRS4 board. The calibration data is read through the function reference:
void DRSBoard :: ReadCalibration (void)
...
      ReadEEPROM (1, buf, 1024 * 32);
      for (i = 0; i <8; i ++)
         for (j = 0; j <1024; j ++) {
            fCellOffset [i] [j] = buf [(i * 1024 + j) * 2];
            fCellGain [i] [j] = buf [(i * 1024 + j) * 2 + 1] / 65535.0*0.4+0.7;
         }
      
      ReadEEPROM (2, buf, 1024 * 32);
      for (i = 0; i <8; i ++)
         for (j = 0; j <1024; j ++)
            fCellOffset2 [i] [j] = buf [(i * 1024 + j) * 2];
...
The Calibrate Waveform is performed by:
int DRSBoard::CalibrateWaveform(unsigned int chipIndex, unsigned char channel, unsigned short *adcWaveform, short *waveform, bool responseCalib, int triggerCell, bool adjustToClock, float threshold, bool offsetCalib)
.....
         for (j = 0; j < n_bins; j++) {
            value = adcWaveform[j] - fCellOffset[channel+chipIndex*9][(j*skip + triggerCell) % kNumberOfBins];
            value = value / fCellGain[channel+chipIndex*9][(j*skip + triggerCell) % kNumberOfBins];
            if (offsetCalib && channel != 8)
               value = value - fCellOffset2[channel+chipIndex*9][j*skip] + 32768;
...
. Because the calibration data reads incorrectly, the Calibrate Waveform does not do it.
Can read calibration data from EEPROM by any command via Oscilloscope application or DRS Command Line Interface application?
Thank you for your help!!!!

You don't have to read and calibrate the waveforms in your user code, but can rely on the DRS.cpp library to do that. Just look at the drs_exam.cpp program coming with the distribution. It uses the function b->GetWave() to retrieve the calibrated waveform. If you like, you can look into that function to learn how to apply the calibration, but I can tell you that it's a bit complicated. Since each event starts at an arbitrary stop cell in the DRS4, you have to "rotate" the calibration array. Then you do actually four calibrations in a row (cell, readout, gain and range).

Stefan

When running drsosc on a raspberry pi, it seems the exit doesn't seem to work at all.  This is true for the "exit" button on the window, or the file menu exit, or the "x" on the window.  I end up having to kill drsosc manually from the command line.  This wouldn't be such a bad thing except that it doesn't seem to store any settings when killed in this way.  I'm wondering if anyone else sees the same thing, or if there is a fix out there, before I go and delve into why.

Unfortunately I don't have a pi here right now, so I cannot reproduce your problem. I checked on a linux system and it worked fine with wxWidgets 3.0.1 and GTK2 2.20. The wxWidget library sends an wxID_EXIT event to DOFrame::OnExit, which then closes the window. The destructor of DOFrame then calls SaveConfig() to save the current settings. Maybe you can debug this.

/Stefan 

I am currently attempting to use a raspberry pi to connect to the DRS 4 board. I whenever I try to use the DRS Command Line TOol, Revision 21435 to connect to the drs board, I get the error

"musb_open: libusb_open() error -3"

"USB successfully scanned, but no boards found"

"No DRS Boards Found".

I successfully compiled the libusb driver before compiling the drs software 5.0.6, and installed all other listed packages in the install instructions.

Have you tried as root? Maybe you miss some permissions.

Stefan

Hi,

According to DRS4's datasheet, the random noise is 0.35mVrms. Is this the input equivalent noise voltage? It is computed over the 0-950MHz frequency band?

Regards.

You cannot compare the DRS4 noise directly with an amplifier for example. The noise mainly comes from variations of the charge injection into the storage cells, and some noise during the readout process, which happens in a completely different frequency domain than the sampling.

So what I did is to keep the inputs open, measure a 1024-bin waveform, and compute the RMS of this waveform. So I believe that this is kind of equivalent noise voltage from 1-950 MHz. It does not start from zero since very low frequency noise (like 50 Hz) just causes a baseline shift and does not influence the RMS, but this is not so important since in most applications people do an event-by-event baseline subtraction to get rid of low frequency noise in their apparatus. The 0.35 mV RMS also depend on the electronics around the chip. On our USB evaluation board the noise it typically smaller (0.31 mV RMS), while in some VME board we measure 0.42 mV RMS. If you do the perfect analog design around the chip, you can maybe push this maybe even lower.

Please find attached a simple ROOT based program (http://root.cern.ch) to decode binary data from the DRSOsc program. It assumes that all four channels were recorded. If this is not the case, the program can be adjusted accordingly.

To use it, simply type (assuming that you have written a data file "test.dat" with DRSOsc):

root [0] .L decode.C+
Info in <TUnixSystem::ACLiC>: creating shared library /tmp/./decode_C.so
root [1] decode("test");
Info in <TCanvas::MakeDefCanvas>:  created default TCanvas with name c1
1927 events processed
"test.root" written
root [2] 

 

/Stefan

Stefan Ritt wrote:

Please find attached a simple ROOT based program (http://root.cern.ch) to decode binary data from the DRSOsc program. It assumes that all four channels were recorded. If this is not the case, the program can be adjusted accordingly. To use it, simply type (assuming that you have written a data file "test.dat" with DRSOsc): root [0] .L decode.C+ Info in <TUnixSystem::ACLiC>: creating shared library /tmp/./decode_C.so root [1] decode("test"); Info in <TCanvas::MakeDefCanvas>:  created default TCanvas with name c1 1927 events processed "test.root" written root [2]  If you have turned on the clock on channel4 of the DRS4 evaluation board, it will produce a plot like this:       /Stefan

I updated this ROOT program for the new format used with the V5 boards. It's now called "read_binary.C". Usage stays the same. There is also a standalone C program "read_binary.cpp". Both are attached. 

The older root macro did not work for me for data acquired with the newest software.

so for the newest software and multiple boards, I modified the read_binary.cpp into read_binary.C for those who like to use the root macro, see the attachment.  

Hello,

Is there a root macro for decoding binary data acquired with the newest software for single board or multi-boards daisy chained?

Cheers,

Abaz

This one elog:361 should still work.

Stefan

Hello,

I have a question about how ROI works. From what I have read, it will only save data that ocurs some time [t_a] dictated by the user after an event is triggered as well as a small time [t_b] before the event. The technical manual seems to indicated that the deadtime assciated with operating in ROI mode can be reduced by the following factor: 

.

Where N is the number of points in the time window (ex. 2048 or 1024). Is it ok to describe this as:

Where N' is the number of samples in the ROI and N is the same as before.

For example, if I were running at 5Gsps (200ps between samples), only recording 1024 samples per event and I had an signal that lasted 2ns, that means the signal would last 10 samples. If I set the ROI to only save 20 samples around this signal, would my Deadtime go to:

? (The second portion of this equation comes from a response I recieved earlier, but I just want to make sure I understand this concept properly)

I recognize that the caveat is that this would work only if the signal was detected during acquistion, which leads to my next question. If no signals were detected in the 1024*200ps time frame in ROI mode, would the DRS4 go dead for 32us (using the factor = 1 from above equation), or would it dump the earliest events in the buffer for the more recent ones until it detects a signal? 

Finally, I assume this functionality can only be utilized with custom electornics with the DRS4, not the evaulation/demo board, please let me know if this is the case. 

Best,

Steven

N'/N is correct. The 2 us "from the response you got from me" come from the fact that after readout, you have to start the DRS4 again. During this time, the power supply usually becomes slightly unstable, and it takes on the evaluation board about 2us to stabilize it again. Tha't why I add the 2 us. If you don't care about slight offset effect, or if you make a better power supply, you dead time would be 10*30ns = 300ns for 10 samples. Starting the DRS again will take one or two clock cycles from the FPGA, which might add another 30 ns or so, depending on how you program the FPGA. So the best you can achieve for 10 samples is maybe 330 ns, if you have a really good power supply (large capacitors).

You can achieve this functionality with the evaluation board, but you would have to make a special firmware for it.

Stefan

Great! That is very helpful. 

One more question. If no signals were detected in the 1024*200ps time frame in ROI mode, would the DRS4 go dead for 32us (or 30us depending on the supply)  for, or would it dump the earliest events in the buffer for the more recent ones until it detects a signal to readout? Or rather, does filling the buffer force a readout or can it dynamically shift out old data until it detects a signal to readout. 

Steven

The DRS4 has an internal storage of 1024 capacitors. They work as a ring buffer, so at 5GSPS you can store 200ns wide signals. After 200ns, the first samples are overwritten by new samples, so you always have the last 200ns of samples stored. Once you trigger the DRS4, this buffer is frozen, and the readout of this buffer causes the dead time. No trigger, no dead time. Hope this answers your question.

Stefan

Hi Stefan,

    according to the DRS4 datasheet, if we want an input range centered around U0, the ROFS should be 1.55V-U0. However when I read the codes of the evaluation board application, ROFS seems to be 1.6V-1.25*U0 where the coefficient 1.25 is said to come from sampling cell charge injection correction. Is it the right equation to use? What exactly does that charge injection correction mean?

    Thanks a lot.

1.55V-U0 is the theoretical values, but there are certain "dirt" effects like chip-to-chip variation and charge injection. The difference between various chips is easily 20-30mV, so there is not a single "correct" value. The formula 1.6V-1.25*U0 I developed for a special evaluation board, where it kind of worked better than the theoretical value, but I never made systematic studies. One should average over several chips and use some solid average there. Best is if you try both formulas and check what give you the better linearity.