DRS4 Forum
  DRS4 Discussion Forum, Page 42 of 45  Not logged in ELOG logo
ID Date Author Subjectup
  828   Wed May 5 10:12:44 2021 Stefan Rittrecording only timestamp and amplitude and/or filesize maximum

The maximum file size depends on the underlying linux file system. Common values are 4-16 GBytes.

Stefan

Abaz Kryemadhi wrote:

Hi,

I have been collecting some date using the DRS4 board at a trigger rate of 10-20 Hz,    I only need the timestamp and the amplitude, is there anyway to select only these two live as the data comes in to be stored. 

Alternatively,  What's the maximum file size or maximum number of events I can store in one binary file in linux. 

Thanks,

Best,

Abaz

 

  313   Tue Nov 26 15:36:39 2013 Dmitry Hitsreducing sampling speed

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 

  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

  514   Wed Apr 27 08:14:14 2016 Toshihiro Nonakaserial number problem

Dear all,

I'm using 3 DRS boards simultaneously and their serial numbers are 2169, 2170, 2172 respectively.

Recently however,  I obtain serial number "0" by DRSBoard::GetBoardSerialNumber() for #2172 board.

Data taking can be done without any problems, but I'd like to know what is happening.

Any advice?

Thank you.

Toshihiro Nonaka

Attachment 1: serial.png
serial.png
  515   Wed Apr 27 09:04:01 2016 Stefan Rittserial number problem

If dis- and reconnecting the board does not help, there is the (small) chance that the serial number got erased in the board. You can re-set it with the "drscl" command line tool:

$ drscl
Found DRS4 board 0 on USB, serial #0, firmware revision 21305
B0> serial 2172

 

Toshihiro Nonaka wrote:

Dear all,

I'm using 3 DRS boards simultaneously and their serial numbers are 2169, 2170, 2172 respectively.

Recently however,  I obtain serial number "0" by DRSBoard::GetBoardSerialNumber() for #2172 board.

Data taking can be done without any problems, but I'd like to know what is happening.

Any advice?

Thank you.

Toshihiro Nonaka

 

  516   Wed Apr 27 09:51:37 2016 Toshihiro Nonakaserial number problem

The serial number has been fixed by using drscl. Thank you!

Stefan Ritt wrote:

If dis- and reconnecting the board does not help, there is the (small) chance that the serial number got erased in the board. You can re-set it with the "drscl" command line tool:

$ drscl
Found DRS4 board 0 on USB, serial #0, firmware revision 21305
B0> serial 2172

 

Toshihiro Nonaka wrote:

Dear all,

I'm using 3 DRS boards simultaneously and their serial numbers are 2169, 2170, 2172 respectively.

Recently however,  I obtain serial number "0" by DRSBoard::GetBoardSerialNumber() for #2172 board.

Data taking can be done without any problems, but I'd like to know what is happening.

Any advice?

Thank you.

Toshihiro Nonaka

 

 

  768   Mon Aug 19 23:01:22 2019 Bill Ashmanskasshould one deassert DENABLE while writing the write-shift register?

Hi Stefan,

We have for some time now been using custom firmware on a custom board to read waveforms out of DRS4 chips.  Now we are working on cascaded readout mode, 4 channels @ 2048 samples, WSREG=0x55, in order to allow for longer trigger latency.

Doing a testbench simulation of the FPGA code raised a question for me:  Do I need to deassert DENABLE while I shift a new 8-bit value into the write-shift register?  What happens if, during the few-hundred nanoseconds it takes to shift 8 bits into the register, the domino wave crosses cell 768, thereby shifting the write-shift register left by one bit?  Is this shifting suppressed when A=0b1101?  Or does the update of the actual write-shift register occur only once, after the 8th SRCLK cycle?  (Maybe one is really shifting bits into a shadow register that is copied all at once into the actual register?)

I notice in simulating your drs4_eval5_app.vhd that if one sets bit 27 ("drs_ctl_dactive") of register 0 (do not deassert DENABLE on trigger), then starts the domino wave (set bit 0 of register 0), then issues a software trigger, then later writes to register 5 (config register, wsreg, etc.), DENABLE is not in fact deasserted during the time when A=0b1100 (conf_setup, conf_strobe) or when A=0b1101 (wsr_setup, wsr_strobe).

But my simulation testbench includes a simplified Verilog model of my interpretation of the DRS4 data sheet, and my simulated DRS4 happened to cause the write-shift register to shift (256 samples before DTAP toggled) during your "wsr_strobe" FSM state, thus corrupting the value that was being shifted into the WSREG via SRIN and SRCLK.

So I'm curious:  to be safe, should one deassert DENABLE before updating the write-shift register, or is it safe to update it even while the domino wave is active and looping?  It seems easy enough to be safe, since we should only need to write to the WSREG once during the setup phase and then let it loop forever.

Many thanks,

Bill

 

 

  769   Tue Aug 20 10:44:45 2019 Stefan Rittshould one deassert DENABLE while writing the write-shift register?

Hi Bill,

you keep DENABLE active all the time to keep the Domino Wave running, but you deassert DWRITE if you change any register via SRCLK. There is no shadow register, just a simple shift register, but with DWRITE being low, the domino circuitry does not touch it.

Best,
Stefan

Bill Ashmanskas wrote:

Hi Stefan,

We have for some time now been using custom firmware on a custom board to read waveforms out of DRS4 chips.  Now we are working on cascaded readout mode, 4 channels @ 2048 samples, WSREG=0x55, in order to allow for longer trigger latency.

Doing a testbench simulation of the FPGA code raised a question for me:  Do I need to deassert DENABLE while I shift a new 8-bit value into the write-shift register?  What happens if, during the few-hundred nanoseconds it takes to shift 8 bits into the register, the domino wave crosses cell 768, thereby shifting the write-shift register left by one bit?  Is this shifting suppressed when A=0b1101?  Or does the update of the actual write-shift register occur only once, after the 8th SRCLK cycle?  (Maybe one is really shifting bits into a shadow register that is copied all at once into the actual register?)

I notice in simulating your drs4_eval5_app.vhd that if one sets bit 27 ("drs_ctl_dactive") of register 0 (do not deassert DENABLE on trigger), then starts the domino wave (set bit 0 of register 0), then issues a software trigger, then later writes to register 5 (config register, wsreg, etc.), DENABLE is not in fact deasserted during the time when A=0b1100 (conf_setup, conf_strobe) or when A=0b1101 (wsr_setup, wsr_strobe).

But my simulation testbench includes a simplified Verilog model of my interpretation of the DRS4 data sheet, and my simulated DRS4 happened to cause the write-shift register to shift (256 samples before DTAP toggled) during your "wsr_strobe" FSM state, thus corrupting the value that was being shifted into the WSREG via SRIN and SRCLK.

So I'm curious:  to be safe, should one deassert DENABLE before updating the write-shift register, or is it safe to update it even while the domino wave is active and looping?  It seems easy enough to be safe, since we should only need to write to the WSREG once during the setup phase and then let it loop forever.

Many thanks,

Bill

  770   Tue Aug 20 16:05:21 2019 Bill Ashmanskasshould one deassert DENABLE while writing the write-shift register?

Aha -- many thanks.  I think what tripped up my test logic is that the "done" state in drs4_eval5_app.vhd that executes post-readout sets DWRITE back to 1 (drs_write_set).  If one then writes to FPGA register 5 while the FSM is in the "idle" state, the conf_strobe and wsr_strobe states occur with DWRITE and DENABLE both asserted.  This is if one sets the "dactive" bit in the FPGA app code, which is probably not the usual use case.  Maybe using the real DRS.cpp avoids this situation.  (I was simulating your FPGA code to test my understanding of what our FPGA code should do.)

Anyway, our own use case is fine: as you suggest, we leave DENABLE asserted, but we deassert DWRITE while reading out or while changing DRS4 register values.

Thanks again,

Bill

 

 

Stefan Ritt wrote:

Hi Bill,

you keep DENABLE active all the time to keep the Domino Wave running, but you deassert DWRITE if you change any register via SRCLK. There is no shadow register, just a simple shift register, but with DWRITE being low, the domino circuitry does not touch it.

Best,
Stefan

Bill Ashmanskas wrote:

Hi Stefan,

We have for some time now been using custom firmware on a custom board to read waveforms out of DRS4 chips.  Now we are working on cascaded readout mode, 4 channels @ 2048 samples, WSREG=0x55, in order to allow for longer trigger latency.

Doing a testbench simulation of the FPGA code raised a question for me:  Do I need to deassert DENABLE while I shift a new 8-bit value into the write-shift register?  What happens if, during the few-hundred nanoseconds it takes to shift 8 bits into the register, the domino wave crosses cell 768, thereby shifting the write-shift register left by one bit?  Is this shifting suppressed when A=0b1101?  Or does the update of the actual write-shift register occur only once, after the 8th SRCLK cycle?  (Maybe one is really shifting bits into a shadow register that is copied all at once into the actual register?)

I notice in simulating your drs4_eval5_app.vhd that if one sets bit 27 ("drs_ctl_dactive") of register 0 (do not deassert DENABLE on trigger), then starts the domino wave (set bit 0 of register 0), then issues a software trigger, then later writes to register 5 (config register, wsreg, etc.), DENABLE is not in fact deasserted during the time when A=0b1100 (conf_setup, conf_strobe) or when A=0b1101 (wsr_setup, wsr_strobe).

But my simulation testbench includes a simplified Verilog model of my interpretation of the DRS4 data sheet, and my simulated DRS4 happened to cause the write-shift register to shift (256 samples before DTAP toggled) during your "wsr_strobe" FSM state, thus corrupting the value that was being shifted into the WSREG via SRIN and SRCLK.

So I'm curious:  to be safe, should one deassert DENABLE before updating the write-shift register, or is it safe to update it even while the domino wave is active and looping?  It seems easy enough to be safe, since we should only need to write to the WSREG once during the setup phase and then let it loop forever.

Many thanks,

Bill

 

  346   Fri May 16 14:04:47 2014 Benjamin LeGeytsimultaneous writing and reading with region of interest mode?

Hello!

We're developing electronics based on the DRS4 to read out a breast PET scanner and our event rate will be quite high so we're concerned about dead-time.  with that in mind, I have a question regarding the mode of simultaneous writing and reading that is described in the DRS4 data sheet.  I think the description there is quite clear but I'd like to ask for a few clarifications.

1) Are the channels required to be read out via the channel multiplexer when doing the simultaneous write/read or is it ok to read out all channels in parallel (even the ones still sampling) and just throw away the ones you don't want?

2) If one wanted to use region of interest mode along with the simultaneous write/read, how would that work?  Here is what I would think - please tell me if I'm missing some important detail:

-upon trigger, deassert dwrite.

-strobe RSRLOAD

-increment write config register

-reassert dwrite

-start the readout (reading out stop shift register value on SROUT as data comes out)

3) now to add even more complexity - I would actually like to use simultaneous write/read along with region of interest mode and also with pairs of cascaded channels as we need >500ns latency and 2Gsps is too slow for our signals.  the combination of cascading and simultaneous write/read is addressed in the data sheet but I still have one question.  In normal circumstances when cascading channels, one would read out the value in the write shift register to know which channel was active when the domino wave stopped.  I assume that this is not possible when dwrite is enabled as the write shift register is then advanced by the domino wave, so I see three possibilities:

-accept more dead-time and read out the write-shift-register each time (adds ~240ns to deadtime)

-just read out both channels every time and figure out later where is the data you want

-attempt to keep track of the expected state of write-shift-register in firmware.

is there a better option that I have not thought of?

 

many thanks!

Benjamin LeGeyt

  347   Mon May 19 08:04:57 2014 Stefan Rittsimultaneous writing and reading with region of interest mode?

Benjamin LeGeyt wrote:

Hello!

We're developing electronics based on the DRS4 to read out a breast PET scanner and our event rate will be quite high so we're concerned about dead-time.  with that in mind, I have a question regarding the mode of simultaneous writing and reading that is described in the DRS4 data sheet.  I think the description there is quite clear but I'd like to ask for a few clarifications.

1) Are the channels required to be read out via the channel multiplexer when doing the simultaneous write/read or is it ok to read out all channels in parallel (even the ones still sampling) and just throw away the ones you don't want?

2) If one wanted to use region of interest mode along with the simultaneous write/read, how would that work?  Here is what I would think - please tell me if I'm missing some important detail:

-upon trigger, deassert dwrite.

-strobe RSRLOAD

-increment write config register

-reassert dwrite

-start the readout (reading out stop shift register value on SROUT as data comes out)

3) now to add even more complexity - I would actually like to use simultaneous write/read along with region of interest mode and also with pairs of cascaded channels as we need >500ns latency and 2Gsps is too slow for our signals.  the combination of cascading and simultaneous write/read is addressed in the data sheet but I still have one question.  In normal circumstances when cascading channels, one would read out the value in the write shift register to know which channel was active when the domino wave stopped.  I assume that this is not possible when dwrite is enabled as the write shift register is then advanced by the domino wave, so I see three possibilities:

-accept more dead-time and read out the write-shift-register each time (adds ~240ns to deadtime)

-just read out both channels every time and figure out later where is the data you want

-attempt to keep track of the expected state of write-shift-register in firmware.

is there a better option that I have not thought of?

 

many thanks!

Benjamin LeGeyt

Unfortunately the simultaneous writing/reading does not work as described in the data sheet. Just recently we found out that due to a bug in the chip a part of the waveform is missing if you read and write at the same time. The only clean solution is to use two DRS4 chips in parallel. You read one chip while the other samples, then you switch over between them. In that case all the ROI scheme and channel cascading works normally. The dead time will be addressed by the DRS5 chip, which will be dead time free, but will not be available until in maybe 2-3 years.

/Stefan 

  668   Wed Mar 14 00:38:15 2018 Will Flanagansub-ms precision timestamps?

Dear DRS4 community,

Is there a way to extract timestamps with sub-ms precision? The milliseconds of an event is clearly given when unpacking the header. I would like to determine how far apart events are when they are within the same millisecond.

Thanks,

Will

  672   Thu Mar 15 08:44:26 2018 Stefan Rittsub-ms precision timestamps?

Putting sub-ms precision into the header does not make sense, since the USB transfer only happens in time-slots of about 2 ms. To get better timing, you would need a hardware time clock in the FPGA, which does not exist right now.

Best,
Stefan

Will Flanagan wrote:

Dear DRS4 community,

Is there a way to extract timestamps with sub-ms precision? The milliseconds of an event is clearly given when unpacking the header. I would like to determine how far apart events are when they are within the same millisecond.

Thanks,

Will

 

  305   Mon Nov 18 15:49:01 2013 Dmitry Hitssynchronisation of readouts of two boards for offline analysis

 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.

  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

  319   Mon Dec 16 11:09:25 2013 Dmitry Hitssynchronisation of readouts of two boards for offline analysis

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

 

 

  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 

  367   Fri Sep 12 11:52:21 2014 Dmitry Hitssynchronizing two DRS4 evaluation boards readout with one computer

 Hi everyone,

Has anyone tried to synchronize 2 (two) DRS4 evaluation boards readout by the same computer? I have read about some attempts on this board in the past, but I do not know if they have succeeded. If yes, could you share your experience and/or software.

Thank you very much,

Dmitry.

 

  368   Fri Sep 12 13:00:04 2014 Stefan Rittsynchronizing two DRS4 evaluation boards readout with one computer

Dmitry Hits wrote:

 Hi everyone,

Has anyone tried to synchronize 2 (two) DRS4 evaluation boards readout by the same computer? I have read about some attempts on this board in the past, but I do not know if they have succeeded. If yes, could you share your experience and/or software.

Thank you very much,

Dmitry.

 

Please read the manual http://www.psi.ch/drs/DocumentationEN/manual_rev50.pdf page 25 where this is described in detail.

/Stefan

  369   Fri Sep 12 13:37:42 2014 Dmitry Hitssynchronizing two DRS4 evaluation boards readout with one computer

Stefan Ritt wrote:

Dmitry Hits wrote:

 Hi everyone,

Has anyone tried to synchronize 2 (two) DRS4 evaluation boards readout by the same computer? I have read about some attempts on this board in the past, but I do not know if they have succeeded. If yes, could you share your experience and/or software.

Thank you very much,

Dmitry.

 

Please read the manual http://www.psi.ch/drs/DocumentationEN/manual_rev50.pdf page 25 where this is described in detail.

/Stefan

 Hi Stefan,

 

Thank you for pointing me to the document. Does it apply only to version 5 of the board or can it be applied also to version 4 (which is the one I have)?

Dmitry

ELOG V3.1.5-fe60aaf