The error probably comes from the fact that the drsosc.exe application is a 64-bit application and cannot be executed under XP any more. Unfortunately XP is forbidden at our institute for security reasons, so I have no machine around where I could compile the executable fro XP. Another problem is the libusb library used by drsosc.exe. Not sure if there is a XP version available any more. Have a look yourself at http://www.libusb.org/wiki/windows_backend 

I only see two possibilities for you: 1) Try to compile the program under Windows XP yourself, either with MS Visual Studio or with MinGW (http://www.mingw.org/). 2) Set up a virtual machine on your PC (for example with Virtualbox), and install either a newer version of Windows or a Linux distribution. The Linux excutable can then be compiled directly from sources as written in the documentation.

Stefan

Hi all

I have a problem with running the DRSOSC under windows XP SP3. We have some hardware which is not supported under newer versions of windows and we would like to use DRS boards along it, therefore we would higly appreciated any help in that direction. We have installed the software (V 5.03) to two different XP machines and got the same problem. The driver installs without any problem, but when the drsosc is run the system says " drsosc.exe is not a valid Win32 application". We have developed our own API for our software which also doesn't recognize the board. It says on the www page that it has been tested for windows XP, but I would appreciate if you can verify it? With best regards and thanks...

Hello Stefan,

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

Abhishek Rajput

No, I can't think of anything else. There is no intermediate addressing stage. The only thing which sometimes happens is that the QFN76 package is not soldered correctly. If you don't have this under control, some pins might have a bad contact. You can check this by touching with a oscilloscope probe not the PCB pads but really the pins from the side, which is a bit tricky.

Stefan

Thanks for replying Stefan.

I was more so just concerned with the steps in the firmware when I had asked. However, yes the ROFS (1.05V) and O-OFS (0.9 V was 1.3 V earlier but, changed this becasue of ADC input requirements) are per spec, the VDD voltages are all there and input voltages are within the rails and finally the RSLOAD  (16 ns) too is ok. Looking at your eval board firmware , on appearance it looks exactly like what I am doing. I thought maybe I was/ still am missing some intermediate addressing stage. What I wrote earlier is what I still have.

Uhh, there are 1000 things which might be wrong. A bit like "my car is not working, it makes strange noise". Without having a look under the hood, there is just some wild guessing:

- Is your ROFS input at the right value? Your O-OFS?

- All VDD voltages there? Input voltage outside the rails?

- Your RSLOAD pulse long enough (>10ns)

- What happens if you put a really big sinal at the input, like 100 MHz sine wave with 2V p-p

The easiest is to have a look at the evaluation board and copy your new board like 1:1, also copy the VHDL readout code. Much easier that to start from scratch.

Stefan

I am having a general problem getting read back using the ROI mode.  In the transparent mode everything looks good. These are the steps that I take:

1) configure register (b"11111111",addr = "1100")

2) configure write shift register (b"11111111", addr = "1101")

3)  assert DENABLE and DWRITE

4) wait for trigger

5) on trigger deassert DWRITE

6) Strobe RSRLOAD

7)Set drs4 address to enable all channels (address = "1001")

8)give n SRCLK pulses

9) goto 3 and repeat.

Am I missing something? Everything looks straight forward based on the manual yet in the readout mode I only get noise. I do get the stop position on SROUT and the refclk is at 475 KHz as desired and I get the desired behaviour  for DTAP toggling at the same frequency as refclk.

You cannot measure times longer than 1024/sampling rate.

Stefan

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,

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;
      }

I don't believe I fully understand how the timing works between multiple channels on DRS4 board, even after reading the manual, but I am hoping to measure a time difference between two channels longer than 1024/sampling rate. So far, I have written a program in Matlab to extract timing and voltage information from the binary file to find the time difference between two channels that are set with the AND trigger logic and appear within approximately 80 ns of each other at a sampling rate of 1 GSPS. This works as intended, but I would now like to try to measure time differences of anywhere between 50 ns and several ms within a single spectrum. Since this is out of the range of only 1024 channels above 1GSPS, is it possible for the board to keep track of the time between two trigger pulses that occur at time differences longer than 1024/sampling rate?

Thank you very much for your help, and if I am severely misunderstanding how the board works, please forgive my ignorance and feel free to correct me,

~Randall

Edit: I forgot to mention that I am collecting the data using the provided DRS4 Oscilloscope software.

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

The serial number is 2586. This board is about two years old, and it might be in use (but I do not know exactly).

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;
      }

Which serial number has the board? Has it been in use before or is it a new board?

Stefan

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.

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;
      }

Cell 700 is arbitrary. You can choose any cell to align the channels to each other. The only requirement is that it's always the same cell for each event. Historically, Daniel chose cell #700 more or less arbitrary, but later we found out that this works with any cell. So for the publication we went with cell #0 (and that's why we have t_ch,0 in the paper), but cell #700 was left in the code because of lazyness. Feel free to replace 700 with any other number and you should get the same result. In a newer version of the software I use

// align cell#0 of all channels
float t1 = time[0][(1024-tc) % 1024];
for (int ch=1 ; ch<8 ; ch++) {
   float t2 = time[ch][(1024-tc) % 1024];
   float dt = t1 - t2;
   for (int i=0 ; i<1024 ; i++)
      time[ch][i] += dt;
   }
 

which is also a bit simpler. So time[ch] contains already the integrated time array (like 0.2 ns, 0.4 ns, 0.6 ns if at 5 GSPS, not the delta_t values as in the DRS.cpp code). Since the readout starts with cell # tc, the cell time[channel][1024-tc] is the physical cell #0 of the chip. The code makes sure that cell #0 in all 8 channels has the same time value.

Best regards,
Stefan

Hello,

Did you start to write some VI to interface DRS4board with labview ?

i also have in mind to do that.I am surprised that nobody alraedy did it since there is no answer toyour question

gerard

Hello,

I have a question about the GetTime() method in DRS.cpp.  I understand how the DT values are applied for all channels, and I also understand from the evaluation board manual that the timing of each channel is synchronized at sample 0, so samples should really be aligned from channel-to-channel relative to sample 0.

However, DRS.cpp has the following snippet in DrsBoard::GetTime():

   if (channelIndex > 0) {
      // correct all channels to channel 0 (Daniel's method)
      iend = tc >= 700 ? 700+1024 : 700;
      for (i=tc,gt0=0 ; i<iend ; i++)
         gt0 += fCellDT[chipIndex][0][i % 1024];
      
      for (i=tc,gt=0 ; i<iend ; i++)
         gt += fCellDT[chipIndex][channelIndex][i % 1024];
      
      for (i=0 ; i<fChannelDepth ; i++)
         time[i] += (float)(gt0 - gt);
   }

I can see what this is calculating and applying such an offset, but I don't understand why things seem to be referenced to sample 700.  Is there a particular reason why sample 700 is chosen here?  This does not seem like a straightforward application of the attached instructions from the evaluation board user's manual.

Any insight would be much appreciated!

Thanks so much,

-Kurtis