DRS4 Forum
  DRS4 Discussion Forum, Page 13 of 45  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
ID Date Authordown Subject
  283   Wed Aug 7 15:10:57 2013 Stefan RittRepeated time calibration

Hermann-Josef Mathes wrote:

Hi,

 

is there any (obvious) reason why it is not possible (or not indended) to repeat the time calibration of a DRS4 eval board several times. I get the shown error message from the 'drscl' tool as well when I try to call the corresponding method in the support library:

mathes@ikauger5:~/src/DRS4> drs-4.0.1/drscl
DRS command line tool, Revision 20430
Type 'help' for a list of available commands.

Found DRS4 board  0 on USB, serial #2362, firmware revision 17662

B0> tcalib
Enter calibration frequency [GHz]: 5
Creating Timing Calibration of Board #2362
[==================================================]
B0> tcalib 5
Creating Timing Calibration of Board #2362
Error performing timing calibration, please check waveforms

 

As I will be in holidays, the answer is not urgent.

Thanks

 -- Hermann-Josef

 

Ups, this is certainly a bug. Try to restart drscl between calibrations. Anyhow the calibration is poor (~20ps), so in a month or two we will have a much better one (~3ps), but that needs a new board (then will be called V5).

/Stefan

 

  286   Mon Aug 12 22:18:39 2013 Stefan Rittadd an average ability to the Scope

tmiron alon wrote:

Right now I'm trying to speed up the number of wavefrom  per second. I'm using your  drs_exam.cpp program you wrote as my basic program. When you wrote it you used the function "b->StartDomino()" inside the loop, which means that before every trigger you gave him a command to start the domino-wave.

From  the "DRS4 datasheet" (page 8) I understand that I can bypass the need to restart the  domino-wave by using "b->SetDominoActive(1)" and "b->SetDominoMode(1)", but when I tried it didn't work (the waveform I got every readout remain the same which means the dominowave froze after the first readout).

Am I understanding wrong or do I need to add somthing more\else so the domino-wave will not stop after each readout? is there any hazard by doing that, as mentiond in page 8 of the the datasheet?

The Domino wave anyhow is always active in mode 1, but you have to enable the writing to the memory cells (via the DENABLE signal). This is done with the b->StartDomino(). You are right that this call takes about 1ms over USB 2.0, so avoiding it would speed up the DAQ by about a factor of two. I have some plans to implement an automatic restart in firmware of the evaluation board, but I won't have time for that until fall of this year.

/Stefan

  295   Mon Sep 23 09:26:56 2013 Stefan RittSampling Frequency: DRS4 eval board

Andrzej Rychter wrote:

Is it possible to set sampling frequency at 100 MHz in DRS4 eval board? Trying to set 0.1GHz in Osci program results in around 0.7 GHz. In drscl.exe i'm able to set freq at 0.1GHz but calibration is impossible.

Thank For Help!

Andrzej Rychter

700 MHz is the minimal sampling frequency. If you need 100 MHz, just buy a "normal" commercial ADC.

 

Best regards,

Stefan 

  300   Wed Nov 6 12:25:31 2013 Stefan Rittflickering screen for drsosc

Dmitry Hits wrote:

Hi,

 

I have install drs software on ASUS EeeBox with Ubuntu 12.04 LTS. When I try to use ./drsosc the oscilloscope window flickers. Can you suggest what might be the problem?

 

Here is some more info:

******************************************************

System:

Ubuntu 12.04 LTS

Memory: 992.9 MiB

CPU: Intel Atom CPU N270 @ 1.6GHz x 2

32 Bit

Disc: 156.5 GB

***************************************

Software:

Due to version Ubuntu I had to install the wxWidgets from source (wxWidgets with x11)

 

Thank you,

 

Dmitry.

This problem is new. Even on a slower Raspberry Pi we did not see any flickering. Have you tried a different version of wxWidgets? 

  301   Wed Nov 6 16:35:42 2013 Stefan Ritt 

lengchongyang wrote:

lengchongyang wrote:

  Hello everyone!I'm a new user of DRS4 board,but it seems that some files are missing in my demo project.So I hope someone could help me by sending a correct VHDL hardware project to my Email:lcyiss900@gmail.com.Thanks in advance!

T

 

 I checked my project today and I think I need the file USR_LIB_VEC_IOFD_CPE_NALL.I don't know if is it a VHD files or a IP core.

I'll be extremely grateful.

 USR_LIB_VEC_IOFD_CPE_NALL is defined in firmware/srs/usr_lib.vhd which is part of the software package.

  303   Thu Nov 14 12:51:56 2013 Stefan RittCascading of channels

Schablo wrote:

 Hello,  I want use cascading of channels for 2048 cell - SetChannelConfig(0,8,4), but i can't understand how . Please, help me. Where i can dowload 2048_mode.ppt. (I found information about this file in DRS.cpp  (3445 line  "/ combine two halfs correctly, see 2048_mode.ppt")

Best regards,

Schablo Kostya 

You have to combine two channels into one, and depending on where the domino wave stopped, things get a bit complicated. I attach 2048_mode.ppt for your reference, but am not sure if this will really help.

/Stefan 

Attachment 1: 2048_mode.pdf
2048_mode.pdf
  306   Mon Nov 18 16:00:26 2013 Stefan Rittsynchronisation of readouts of two boards for offline analysis

Dmitry Hits wrote:

 Dear Stefan,

I am trying to synchronise the readout of two test boards, one is the DRS4 test board, the other is PSI46 test board (used for the readout of  CMS pixel chip) for the offline analysis. I think that the most secure way to accomplish this is to pass a trigger number from one test board to the other.

The PSI46 test board has a software which allows it to accept a 16 bit number following the trigger pulse. I was wondering whether it would be possible for DRS4 board to generate such a trigger number on the trigger out line after sending the trigger. Also would it be possible to record this trigger number for every event stored by DRS4 board?

If none of this possible or requires a lot of time, then as a minimum, would it be possible to send-through only the triggers that were recorded by the DRS4 board?

Please let me know if you have better idea how to do this.

Thank you very much,

Dmitry.

There are indeed several methods. You can output the trigger number at the DRS evaluation board via the trigger output, but you would have to implement this yourself in the firmware.

The send-though of recorded triggers is already implemented in the board, so you could use that. The only thing to make sure is to to readout and re-enable the PSI46 board before you readout the DRS4 board. If you would first read the DRS4 board, and re-enable the DRS4 board via StartDomino(), then there could be the next trigger going through to the PSI46 board without that board being ready. So the sequence is

- connect trigger out of DRS4 to PSI46

- arm PSI46 board

- arm DRS4 board

- wait for trigger by calling IsBusy()

- read out PSI46 board

- read out DRS4 board

- call StartDomino(), which re-enables also the trigger though

 

Best regards,

Stefan

  308   Tue Nov 19 09:09:01 2013 Stefan RittDRSOsc at Mac OS X Mavericks

Andriy Zatserklyaniy wrote:

I installed Mac OS package on macbook (late 2013). DRSOsc starts to write file but freezes; need to be restarted to restore connection with DRS4 evaluation board (ordered Aug 2011). 

DRSOsc seems broken on OSX 10.9. I'm working on this right now. Some of the problems are related to wxWidgets, so I'm waiting for a new version running stably under OSX 10.9. The compilation problem related to "strlcpy" comes from the fact that OSX 10.9 now comes with its own version of that function, while all previous versions did not. So simply removing strlcpy.h/c from the project fixes that.

There will be a new version of DRSOsc next month which fixes all this problems, so just stay tuned.

/Stefan 

  310   Wed Nov 20 08:16:10 2013 Stefan RittDRSOsc at Mac OS X Mavericks

Andriy Zatserklyaniy wrote:

When I launch DRSOsc.app/Contents/MacOS/DRSOsc from terminal, I see constantly pouring messages about fonts:

2013-11-19 12:21:22.232 DRSOsc[99520:507] CoreText performance note: Client called CTFontCreateWithName() using name "Lucida Grande" and got font with PostScript name "LucidaGrande". For best performance, only use PostScript names when calling this API.

2013-11-19 12:21:22.275 DRSOsc[99520:507] CoreText performance note: Client called CTFontCreateWithName() using name "Lucida Grande" and got font with PostScript name "LucidaGrande". For best performance, only use PostScript names when calling this API.

Another problem: I was not able to save data in binary (*.dat) file. I used DRSOsc settings to set binary format, I specified explicit extension *.dat, tried everything (including hiding extension), but was not able to save in binary format. Do I need to apply some trick? How may I hardcode usage of the binary format?

The CoreText issue comes from WxWidgets or a combination with OSX 10.9. Many other people have the same problem:

https://bugzilla.mozilla.org/show_bug.cgi?id=934261

and I have no idea how to get rid of it.

Concerning your problem with the binary format, just have a look at elog:272

 

  312   Thu Nov 21 14:45:56 2013 Stefan RittCascading of channels

Schablo wrote:

Stefan Ritt wrote:

Schablo wrote:

 Hello,  I want use cascading of channels for 2048 cell - SetChannelConfig(0,8,4), but i can't understand how . Please, help me. Where i can dowload 2048_mode.ppt. (I found information about this file in DRS.cpp  (3445 line  "/ combine two halfs correctly, see 2048_mode.ppt")

Best regards,

Schablo Kostya 

You have to combine two channels into one, and depending on where the domino wave stopped, things get a bit complicated. I attach 2048_mode.ppt for your reference, but am not sure if this will really help.

/Stefan 

Sorry for my question.

 I'm trying change "drs_exam.cpp" for read 2048 cell. 

I'm using SetChannnelConfig(0,8,4) and this code in "drs_exam.cpp" :

              ...

              float arrX[2048];

              float arrY[2048];

              ....

             b->GetTime(0, b->GetTriggerCell(0), arrX);

             b->GetWave(0, 0, arr.Y); 

             ....

Return 2048 values in arrX[2048] - correct values, but  in arrY[2048] -  not correct values.

   I can't understand what values return "GetWave" function. Please, say me how make, that GetWave function return correct values.  " not - correct values "(i mean that i give signal in drs bord and values not true.) 

Best regards,

Schablo Kostya 

 

The evaluation board V4 does not support cascading by default. You have to connect each input to two channels, which can in principle be made by soldering some zero Ohm resistors on the board, but these are tiny parts and not everybody can do it. Note that the 2048 cell mode is an option when ordering the board. So first make sure that you can modify the board before trying to run the software. 

  314   Tue Nov 26 15:38:13 2013 Stefan Rittreducing sampling speed

Dmitry Hits wrote:

Dear Stefan

Is there an easy way to reduce sampling speed below 0.7 GSPS? I would like to record traces up to 5 usec long.

Thank you

Dmitry 

No. See the DRS4 datasheet: http://www.psi.ch/drs/DocumentationEN/DRS4_rev09.pdf 

Minimum sampling speed is 700 MSPS.

 

/Stefan

  316   Tue Dec 10 14:54:46 2013 Stefan Rittmeasurement range

ismail okan atakisi wrote:

I m trying to measure lifetime in our lab and I intend to take
measurement with DRS4 at that point I have a little bit confused about
DRS4 time range.In My system I opened 10 us gate but after triggering
DRS4 measure nearly 1.2 us. Because of this I want to extend DRS4 time range that
measurement range from 1.2us to 10 us.  

Have a look at the Evaluation Board description at http://www.psi.ch/drs/evaluation-board. It says that you have 1024 sampling points per channel. So If you sample at 0.7 GSPS, this gives you a time range of 1/0.7 GHz * 1024 = 1.46 us.

Best regards,
Stefan

  318   Fri Dec 13 11:37:58 2013 Stefan Rittinput protection in DRS4 evaluation board

Dmitry Hits wrote:

Last month I was using a DRS4 evaluation board to digitise the signal from the charged particles in piM1 beam line at PSI. The beam in piM1 is a mixture of pions with a small percentage of protons. Pions are close to minimum ionising and were producing the signals on the order of 250 mV (Landau distributed). The protons at this momentum (250 MeV) are not minimum ionising  and produced much higher signals ( I could not exactly measure them because they were of scale for the DRS4 board). The pulses were on the order of 0.5 usec long. At low rate (~1kHz) the board was able to handle them, but when I turned the rate of particles to about ~300 kHz, the channel went flat. My question is whether the evaluation board has some type of input protection that would be possible to replace? Or does that mean that I have burned the input of the DRS4 board itself? Other channels behaving normal.

As written in the manual, the board withstands +-20V pulses which are shorter then 2 usec, and a DC input of +-10V. If your pulses are bigger or longer, you will kill the input buffer chip, which needs to be re-soldered. You can check if the channel is broken by applying a periodic signal of known amplitude (e.g. a 100 mV 1 MHz sine wave). If the measured amplitude differs significantly from the others (like only half the amplitude) or is completely flat, you burned the input stage. When you are next time at PSI you can bring the board and we can then fix it.

/Stefan

  320   Tue Dec 17 08:45:32 2013 Stefan Rittsynchronisation of readouts of two boards for offline analysis

Dmitry Hits wrote:

Stefan Ritt wrote:

Dmitry Hits wrote:

 Dear Stefan,

I am trying to synchronise the readout of two test boards, one is the DRS4 test board, the other is PSI46 test board (used for the readout of  CMS pixel chip) for the offline analysis. I think that the most secure way to accomplish this is to pass a trigger number from one test board to the other.

The PSI46 test board has a software which allows it to accept a 16 bit number following the trigger pulse. I was wondering whether it would be possible for DRS4 board to generate such a trigger number on the trigger out line after sending the trigger. Also would it be possible to record this trigger number for every event stored by DRS4 board?

If none of this possible or requires a lot of time, then as a minimum, would it be possible to send-through only the triggers that were recorded by the DRS4 board?

Please let me know if you have better idea how to do this.

Thank you very much,

Dmitry.

There are indeed several methods. You can output the trigger number at the DRS evaluation board via the trigger output, but you would have to implement this yourself in the firmware.

The send-though of recorded triggers is already implemented in the board, so you could use that. The only thing to make sure is to to readout and re-enable the PSI46 board before you readout the DRS4 board. If you would first read the DRS4 board, and re-enable the DRS4 board via StartDomino(), then there could be the next trigger going through to the PSI46 board without that board being ready. So the sequence is

- connect trigger out of DRS4 to PSI46

- arm PSI46 board

- arm DRS4 board

- wait for trigger by calling IsBusy()

- read out PSI46 board

- read out DRS4 board

- call StartDomino(), which re-enables also the trigger though

 

Best regards,

Stefan

 Dear Stefan

Thank you very much for the answer. I did not have a chance to implement this yet.

I have a  follow up question: 

Is the following sequence already implemented in the DRS oscilloscope program? Could you point me to an example of such a sequence?

- arm DRS4 board

- wait for trigger by calling IsBusy()

- read out DRS4 board

- call StartDomino(), which re-enables also the trigger through

 

Cheers

Dmitry

 

 

Have a look at the drs_exam.cpp program which comes with the software, it implements exactly this sequence.

/Stefan 

  322   Thu Jan 9 11:02:46 2014 Stefan Rittv5 software with v4 board calibration

Martin Petriska wrote:

 Hi

Question:

In v4 board, which channel has best calibration ?

Should it be possible to simulate v5 board and read calibration values for v4 board by other method .. for example using external calibration signal source connected to all channels? 

Is it  needed to detach all input signals from EVM board during calibration ?( I see there are switches on channel inputs.)

Some comments: averager.h, averager.cpp are missing in windows v.5 sources (it should be copied from linux sources)

 

PF2014 and thank You for development new EVM 5 and new time precision.

 

Martin

In v4 board, actually no channel has a good calibration. The timing calibration is done with channel #9, which is hard connected to a (poor) clock. So the best you can get there is ~30 ps. In principle one can calibrate the V4 board with an external source. The problem there is to find a good sine wave oscillator (we have several expensive ones and only one was good enough), and that the software does not support this. You would have to write your own calibration code (where of course you can "recycle" the one from the V5 software.

Thanks for pointing out the missing averager.*, I will add it.

/Stefan

  323   Wed Jan 15 14:20:51 2014 Stefan RittAnnouncement of new Evaluation Board V5

Dear DRS community,

starting from this year, we ship the new evaluation board V5. This board has an improved internal timing calibration, with which one can measure the time with a precision down to a few ps. Following picture shows the time between two pulses, obtained with a function generator, a passive split and a delay cable. The single threshold time estimator of the DRSOsc program obtains with such signal a resolution of 2.5 ps (RMS):

drsosc.png

 

Using more sophisticated algorithms such as cross-correlation, resolutions below 1 ps were already achieved.

The new board can now be ordered at the same price than the V4 board, delivery will start in March 2014.

Best regards,
Stefan Ritt
 

  324   Wed Jan 15 15:48:55 2014 Stefan RittUSB connection stops
Hi,

finally I found some time to look into this problem, sorry for the late delay.

I tried your program and started it maybe 50 times without an issue. So I cannot reproduce your problem.

I know that if you do Ctrl-C then you might have some data "stuck" in the USB interface, like you ask for a 
waveform data buffer but you never read it because you got interrupted by the Ctrl-C. But when you reinitialize 
the board the next time, all stuck data is drained before the board is initialized. This is done in DRS.cpp 
around line 343:

            /* drain any data from Cy7C68013 FIFO if FPGA startup caused erratic write */
            do {
               i = musb_read(usb_interface, 8, buffer, sizeof(buffer), 100);
               if (i > 0)
                  printf("%d bytes stuck in buffer\n", i);
            } while (i > 0);


So occasionally, after a restart after a Ctrl-C, you will see "xxx bytes stuck in buffer", but then the boards 
should come up correctly.

If you have the problem without Ctrl-C, then maybe your specific board has a hardware problem? Do you have 
access to another board? 

Best regards,
Stefan
  325   Wed Jan 15 16:15:00 2014 Stefan RittSome bug fixes and questions

Andrey Kuznetsov wrote:

  For http://www.psi.ch/drs/DocumentationEN/manual_rev20.pdf:

0 0x02 15..8 board_type 5 for DRS4 USB Evaluation Board 1.1 ---> should instead say Evaluation Board 2.0 ?

Type 5 is both for board V1.1 and V2. I consider V1.1 obsolete (nobody uses it). I added code 8 for V4 and 9 for V5 

Andrey Kuznetsov wrote:

 1) if(i==100) should be if(i==1000) in function int DRSBoard::SetFrequency(double demand, bool wait)

Otherwise if PLL did not lock, i = 1000, and the if statement is evaluating it against 100, not 1000 so it never gets triggered and the error goes unnoticed.

      if (wait) {
         StartDomino();
         for (i=0 ; i<1000 ; i++)
         if (GetStatusReg() & BIT_PLL_LOCKED0)
            break;
         SoftTrigger();
         if (i==100) {
            printf("PLL did not lock for frequency %lf\n", demand);
            return 0;
         }
      }

 Absolutely correct, I changed it in the current software.

 

Andrey Kuznetsov wrote:

 2) int DRSBoard::RegulateFrequency(double demand) does not seem to work at all, the frequency does not lock for either 2 or 5 GHz, tested using DRS4 v2.0 eval board with DRS v4.0.1 and v2.0.1 software's drscl tool.

 This function is for the old DRS2 chip back in 2003 or so. That chip did not have an on-chip PLL for frequency regulation, so this was done in the FPGA. Just don't us it (who told you to???). 

 

Andrey Kuznetsov wrote:

3) In int DRSBoard::SetTriggerDelayPercent(int delay) and int DRSBoard::SetTriggerDelayNs(int delay), what is the purpose of Read and setting of "reg" if it's not being used or exported anywhere else outside of that function? Seems like Read and reg are called for nothing.

      Read(T_CTRL, &reg, REG_TRG_DELAY, 2);
      reg = (reg & 0xFF00) | ticks;
      Write(T_CTRL, REG_TRG_DELAY, &ticks, 2);

Also, I don't understand why in int DRSBoard::SetSyncDelay(int ticks), the code changes to 
      Read(T_CTRL, &reg, REG_TRG_DELAY, 2);
      reg = (reg & 0xFF) | (ticks << 8);
      Write(T_CTRL, REG_TRG_DELAY, &reg, 2);

In particular, reg = (reg & 0xFF00) | ticks; and reg = (reg & 0xFF) | (ticks << 8);  I'm not really sure but doesn't Read() with size 2 return a value that has a maximum value of 0xFF, or 8bits?   But ticks << 8, since ticks == 255 max, makes 255 << 8 => 65280, which is now a 16bit value and size 4. No? I might be wrong here, and if I am then I don't understand what's going on.   Can you please explain? In v2.0.1 the ticks were a maximum of 511 or 9bits, why did it change to 8bits?

The register REG_TRG_DELAY contains two 8-bit values, one for the trigger delay, one for the sync delay (which is currently not used). So to set one half of the register containing 16 bits, the register is read (16 bits are read with size 2, since these are two bytes), and the upper or lower 8 bits are replaced with the new value. Then the 16 bits are written back. The firmware in the FPGA does not allow to access only 8 bits of a 16-bit register.

 

Andrey Kuznetsov wrote:

 

4) A function is being called incorrectly in GetWave() in DRS.cpp

int DRSBoard::GetWave(unsigned int chipIndex, unsigned char channel, float *waveform)
{
   return GetWave(chipIndex, channel, waveform, true, fStopCell[chipIndex], false, 0, true);
}

The return is calling the following overloaded function:
int DRSBoard::GetWave(unsigned int chipIndex, unsigned char channel, float *waveform, bool responseCalib, int triggerCell, int wsr, bool adjustToClock, float threshold, bool offsetCalib)
the problem is that int wsr is not passed to the function and it thus causes implicit conversions where false is being cast into int, 0 into bool, and true into float.

That's correct. Fortunately the wrong values for the wsr does not have any influence for "normal" users. It is only used for channel cascading which is not used in the evaluation board. I will fix it in the code anyhow.

  326   Wed Jan 15 17:02:58 2014 Stefan RittSome bug fixes and questions

Andrey Kuznetsov wrote:

 So although it doesn't affect data retrieval, it's just dumb luck the function ends up being called with parameters that matter being exactly what they were meant to be.

Exactly. If I would not have had that dumb luck, I would have seen the problem and fixed it. So it was more like bad luck. 

  327   Wed Jan 15 17:11:14 2014 Stefan RittSome bug fixes and questions

Andrey Kuznetsov wrote:

The DRSCallback *pcb is missing an if statement in the code when DRS Oscilloscope software isn't used when calibrating in function: int DRSBoard::CalibrateTiming(DRSCallback *pcb)

I had to add if (pcb != NULL) before each pcb call, like other functions are using so that the program doesn't segfault when the function is called like b->CalibrateTiming(NULL);

 

That's the only function that's missing this if statement for DRSCallback *pcb call, and there are 2 calls in this function to pcb that need fixing.

Acknowledged. Added it to the code. 

ELOG V3.1.5-fe60aaf