DRS4 Forum
  DRS4 Discussion Forum, Page 1 of 15  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
Entry  Mon Dec 15 13:37:38 2008, Stefan Ritt, Welcome 

 Welcome to the DRS4 Discussion Forum. This forum contains information and discussions related to the DRS4 chip. Please subscribe to this forum to receive automatic email updates. If you have any technical questions, please feel free to post it here.

Entry  Wed Jan 14 12:02:04 2009, Stefan Ritt, External Trigger Input requirements tap.jpg

Several people mentioned that the external trigger input (TTL) does not work on the DRS4 Evaluation Board Rev. 1.1. This is not true. The requirement however is that the input signal must exceed approximately 1.8V. Since the input is terminated with 50 Ohms, not all TTL drivers may deliver enough current to exceed this threshold. To verify this, the trigger signal can be monitored with an oscilloscope at test point J24. Only if the input signal exceeds 1.8V, the signal will be seen at J24 and correctly trigger the FPGA. If the TTL driver is too weak, the termination resistor R9 can be optionally removed, but care should then be taken that reflections in the trigger input do not cause double triggers. The locations of the tap point for the input signal, the termination resistor R9 and the tap point J24 after the input level converter U5 are shown in this image:

tap.jpg

    Reply  Wed Jan 14 13:41:44 2009, Stefan Ritt, External Trigger Input requirements 

 

Another tricky issue comes from the fact that the external TTL trigger and the comparator are in a logical OR. So if the comparator level is set such that the signal is always over the threshold, the trigger is always "on" and the TTL trigger does not have any effect. It is therefore necessary to set the analog trigger level to a very high value in order to make the TTL trigger work. 

Entry  Wed Feb 11 12:21:07 2009, Stefan Ritt, Corrected datasheet Rev. 0.8 

 Please note the new datasheet Rev. 0.8 available from the DRS web site. It fixes the label of pin #76, which was AGND but is actualy AVDD. The input IN8+ is located at pin #20 and not at pin #19 as described in the old table 2.

Entry  Mon Feb 23 09:24:24 2009, Stefan Ritt, Rise-time measurements image001.jpgimage003.jpgsingle.jpg

Many applications using the DRS4 need to measure fast rising signals, like for PMTs or MCPs. This short note shows the minimal rise-times which can be measured with different input signal conditioning.

Evaluation Board

The evaluation board contains four passive transformers ADT1-1WT from Mini-Circuits to convert the single-ended input signal into a differential signal. Although these parts are rated 800 MHz bandwidth (-3dB), they have hard time to drive the DRS4 inputs. This is because at high frequencies the input impedance of DRS4 becomes pretty small (~20 Ohm at 500 MHz) due to its capacitive nature. Furthermore, each transformer drives two DRS4 inputs (channel cascading) which enhances this problem by a factor of two. We made a quick test sending a signal to the evaluation board with a rise time of 277ps and a fall time of 280ps. The result measured with the evaluation board is seen here:

image001.jpg

The measured rise-time (10%-90%) is only about 2ns. Disconnecting the second channel from each transformer improves this situation a bit:

single.jpg

so the rise-time comes down to ~1.6ns.

Active ADA4937 driver

We tested the behavior using an active buffer ADA4937 to replace the passive transformer. Without the DRS4 connected to this buffer, we measured with the oscilloscope a rise time of 408ps and a fall time of 644ps. When we connect the DRS4 (single channel), this values increase to 702ps (rise) and 1400ps (fall), all measured with a differential oscilloscope probe (WL300 4 GHz Bandwidth, LeCroy 7300A, 3 GHz Bandwidth). In this case the rise time seen by the DRS4 is wieth ~700ps accordingly shorter:

image003.jpg

(The signal was not properly terminated and therefore we have a small overswing). 

Conclusion

To obtain an optimal rise-time measurement, the design of the input stage is rather important. A fast active driver seems to do a better job than a passive transformer (which was used on the evaluation board for power reasons). Connecting only one DRS4 channel to the input improves the rise-time measurement significantly. If channel cascading is still needed, a design should use one driver for each channel, and not driver two or more DRS4 inputs from a single buffer.

If anybody comes up with an even better input driver, I'm happy to publish the results here.

Entry  Mon Apr 27 15:09:49 2009, Stefan Ritt, Amplitude and Timing calibration for DRS4 Evaluation Board uncal.pngcal.png

This is a quick notification to all users of the current DRS4 evaluation board.

As you all know, the DRS4 chip needs some calibration for each individual cell which corrects the offset and the non-equidistant width in time. While the first evaluation boards have been shipped without this calibration, the current version of the software implements a full amplitude and timing calibration. The offset correction reduces the noise of the board by almost an order of magnitude to below 1 mV RMS. The timing calibration using an on-board reference clock allows a timing accuracy in the order of 10 ps. To illustrate that the following two pictures show a reference clock signal before and after timing calibration:

uncal.png

cal.png

The integral temporal nonlineairy at 5 GSPS before timing calibration is about 600 ps as can be seen by the jitter of the overlaid waveforms.

In order to do a timing calibration, the firmware revison 13297 or later is required. The current software package 2.1 contains an updated firmware, but unfortunately one needs a Xilinx download cable to flash this new firmware (see http://drs.web.psi.ch/download/ under "Software Versions"). If some people want an update but do not want to buy such a cable, we offer a free update at our institute (just the postage has to be paid). The old evaluation board (Rev. 1.0, plastic housing) can unfortunately not be updated.

After the offset calibration is made, there are small (~20mV) short spikes left. They probably come from some cross-talk between the USB interface and the analog part of the board. This is currently under investigation. If new updates become available, they will be announced in this forum.

 

April 27th, 2009,

Stefan Ritt

Entry  Wed Jun 10 12:46:43 2009, Stefan Ritt, Input range switch added in Version 2.1.3 Capture.png

 A new software verison for the DRS4 Evaluation Board has been has been released. Version 2.1.3 adds a switch for the input range of the DRS4 board. Once can choose between -0.5V...0.5V and 0V...1V:

Capture.png

A board firmware update is not necessary for this. It was originally planned to have even a negative range -1V...0V, but this is not possible with the current board design. People who want to record negative pulses have to use an inverter to produce positive pulses. In a future version of the board it might be possible to include this functionality since this is determined by the analog front-end and not the DRS4 chip.

Entry  Tue Jul 7 16:39:57 2009, Stefan Ritt, Power up problem and remedy typical_mode.gif

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.

Entry  Thu Jul 9 09:11:03 2009, Stefan Ritt, Current problems with drs_exam.cpp 

The current version of the DRS readout example program drs_exam.cpp has two problems:

  1. The sampling frequency cannot be changed, it will always stay in the region around 5 GSPS
  2. The waveform obtained by GetWave is rotated such that the first DRS cell corresponds to the first array bin

Both problems have been fixed and the fix will be contained in an upcoming software release.

Entry  Tue Oct 6 11:20:39 2009, Stefan Ritt, VDD instability vdd_no_cap.pngvdd_470uf.png

It has turned out that the stability of the AVDD and DVDD power supplies for the DRS4 are very critical. On the evaluation board I use a REG1117-2.5, on our VME board I use a ADP3338-2.5 for the DVDD power supply. When the domino wave is started, the power consumption of the DRS4 chip jumps up by ~40 mA, which has to be compensated by the linear regulator. Following screen shot shows what happens:

vdd_no_cap.png 

The blue trace is the DWRITE signal indicating the sampling phase when high. The yellow is the SRCLK showing when the readout takes place. The pink is now the DVDD power. It can be clearly seen that there is a dip of ~50 mV when the domino wave starts, a positive dip when it stops and another smaller dip when the readout starts. This causes strange effects: If the trigger arrives during the first dip, the actual sampling takes place when the DVDD is ~50 mV smaller, which leads to a baseline shift of a sampled 0V DC input voltage of about the same amount (-50 mV).

The obvious improvement is to put a huge capacitor on the power supply, but that does not help much:

vdd_470uf.png

The dip gets a bit smaller, but it's still there. So a better solution would be to use a faster LDO regulator. Please take care of this if you plan a new design.

Furthermore, I believe that the chip internally has some "warmup" phase, where the die heats up a bit when the additional 40 mA are drawn. So a "good" solution is to wait some time after starting the domino wave until one allows for triggers. Tests showed that a few milliseconds are necessary to keep the baseline shifts below a few millivolts. This of course decreases the dead time of the system significantly, so one has to choose the proper balance between increase dead time and increased base line shift. On some applications where a baseline shift is not an issue, one could opt for the minimum dead time.

Entry  Wed Oct 7 17:58:20 2009, Stefan Ritt, VDD switch off speed no_res.png100ohm.png

It turned out that the VDD switch off speed plays some important role. On our VME board, we have a linear regulator, then a 4.7 uF capacitor, then the DRS4 chip (DVDD and AVDD). When switching off the VME power, it takes quite some time to discharge the 4.7 uF capacitor, since the DRS4 chip goes into a high impedance mode if VDD < ~1V. This gives following VDD trace:

no_res.png 

Rising edge is power on, falling edge is power off. Note the horizontal time scale of 2 s/div. So to get below 0.3 V or so, it takes up to 30 seconds. If the power is switched back on when AVDD is above 0.3V, the DRS4 chip can get into a weird state, where probably many domino waves are started and the chip draws an enormous amount of current. Typically the linear regulator limits the current, so the 2.5V drops to ~1.5V, and the board is not working. If people are aware of this and always wait >30sec. before turning the power on again, this is fine, but people might forget.

So the solution is to put a resistor (typically 100 Ohm to 1 kOhm) parallel to the 4.7 uF capacitor in order to have some resistive current load of a few mA. The discharge then looks like this:

100ohm.png

Note the horizontal scale of 10ms/div. So after 30 ms AVDD is discharged and powering on the chip again does not do any harm. The same should be done to DVDD.

Entry  Wed Oct 14 23:53:05 2009, Armin Kolb, DRS_exam using USB Evaluation Board with OS X Makefile

For the users using a Macintosh,

after several hours the Evaluation Board is working  on my Macintosh (intel).

1) install the development package with xcode, its on the OS X installation DVD

2) install the libusb binary from http://www.ellert.se/twain-sane/

3) modify the makefile  for compiling drs_exam (attached) afterwards it's running perfect!

 

best,

Armin

 

Entry  Fri Oct 16 09:51:03 2009, Jinhong Wang, DSR4 Full Readout Mode 

Hello Mr. Stefan Ritt

          In DSR4 DATASHEET Rev.0.8 Page13, I noticed you metioned the samping should occur after 38 ns after the rising edge of SRCLK when the multiplexer is used. So what is suggested value(delay time between sampling and the rising edge of SRCLK) for the parallel mode,in which the multiplexer is not used?

          Best wishes!

                                                       Jinhong Wang

    Reply  Fri Oct 16 10:16:10 2009, Stefan Ritt, DSR4 Full Readout Mode 

Jinhong Wang wrote:

Hello Mr. Stefan Ritt

          In DSR4 DATASHEET Rev.0.8 Page13, I noticed you metioned the samping should occur after 38 ns after the rising edge of SRCLK when the multiplexer is used. So what is suggested value(delay time between sampling and the rising edge of SRCLK) for the parallel mode,in which the multiplexer is not used?

          Best wishes!

                                                       Jinhong Wang

The clock-to-output delay is the same if one uses the multiplexer or not. I found however that in most cases the delay of 38 ns needs some fine tuning to get optimal performance. So I typically use a shifted clock generated by the FPGA clock manager with a programmable delay (+-5 ns for Xilinx) and optimize this in the running system.

Entry  Mon Oct 19 09:06:43 2009, Jinhong Wang, BIAS Pin of DRS4 

Dear Mr. Stefan Ritt.

         Thank u for your timely response on "DSR4 Full Readout Mode", I received it from Professor Qi An, who is my PhD supervisor.

        I am currently going through the DRS4 datasheet. Well, can you give some specification on the usage of "BIAS" pin of DRS4? It is just metioned in the datasheet as bias of internal buffer. What is the internal buffer exactly reffered to here? The MUXOUT buffer of channel 8 or else? Does it have some relationship to O_OFS? I mean, if the reference voltage to BIAS is changed, how will the output be influenced?

       Looking forward to hearing from you soon.

                                                                       Jinhong Wang

                                                                    Fast Electronics LAB. of University of Science and Technology of China.

    Reply  Mon Oct 19 09:13:00 2009, Stefan Ritt, BIAS Pin of DRS4 

Jinhong Wang wrote:

Dear Mr. Stefan Ritt.

         Thank u for your timely response on "DSR4 Full Readout Mode", I received it from Professor Qi An, who is my PhD supervisor.

        I am currently going through the DRS4 datasheet. Well, can you give some specification on the usage of "BIAS" pin of DRS4? It is just metioned in the datasheet as bias of internal buffer. What is the internal buffer exactly reffered to here? The MUXOUT buffer of channel 8 or else? Does it have some relationship to O_OFS? I mean, if the reference voltage to BIAS is changed, how will the output be influenced?

       Looking forward to hearing from you soon.

                                                                       Jinhong Wang

                                                                    Fast Electronics LAB. of University of Science and Technology of China.

"internal buffers" are all internal operational amplifiers in the DRS4 chip. Every OPAMP needs a bias (just look it up in any electronics textbook), which determines the linearity and the speed of the OPAMP. When designing DRS4, I was not sure if the required BIAS voltage changes over time, or between chips, so I made it available at a pin, which is a common technique in chip design. But it turns out now that this voltage is not very critical, so just keeping the pin open will work in most cases. 

Entry  Mon Oct 19 11:26:29 2009, Jinhong Wang, output common mode voltage of DRS4 
Hello Mr. Stifan.Ritt
       In the DSR4 datasheet, it is mentioned that there is an additional buffer at each analog output, this buffer shifts the the differential range of -0.5V~0.5V to 0.8V~1.8V. Does it mean that this buffer shifts a voltage of about 1.3V for the primary differential range? 
       Again for the differential range of -0.5V~0.5V, can the common mode voltage of the analog output at OUT+/OUT-  be chaned? In the example presented in the datasheet, OUT+ is 0.8V~1.8V and OUT- is 1.8V~0.8V. So for an output swing of 2V p-p, can the common mode voltage be modified to the desired value? Supposed that the input ranges from -0.5V~0.5V.
                                                      
     Thank you!
                                             Jinhong Wang
    Reply  Mon Oct 19 12:46:12 2009, Stefan Ritt, output common mode voltage of DRS4 

Jinhong Wang wrote:
Does it mean that this buffer shifts a voltage of about 1.3V for the primary differential range? 

No. It shifts about ROFS-0.25V. So only if ROFS=1.55V, the shift will be 1.3V.

Jinhong Wang wrote:
Again for the differential range of -0.5V~0.5V, can the common mode voltage of the analog output at OUT+/OUT-  be chaned?

Just read the datasheet under "ANALOG OUTPUTS". I'm sorry if I did not describe this clearly, but the U+ voltage is fixed (only dependent on ROFS), and U- can be calculated using Uofs as written in the datasheet. 

Jinhong Wang wrote:
In the example presented in the datasheet, OUT+ is 0.8V~1.8V and OUT- is 1.8V~0.8V. So for an output swing of 2V p-p, can the common mode voltage be modified to the desired value? Supposed that the input ranges from -0.5V~0.5V.

OUT+ is 0.8V~1.8V, OUT- is 2*Uofs-OUT+. So you can only change the OUT- level, not the OUT+ level. 

Entry  Fri Oct 30 03:31:54 2009, Jinhong Wang, outline dimension of DRS4 QFN_package.jpg

QFN_package.jpg

                                                                                                            Fig.1        typical dimension of QFN package

Above is the typical dimension specification for QFN package. I cann't find the corresponding "T1" as in Fig.1 in the DRS4 documents, nor any of the tolerance of the dimensions, which are usually expressed in the form of  a range between a min. value and a max. value.

So will you specify the dimension of "T1" and "W1", and the dimension tolerance of them?

Thanks and best wishes!

                                                                               Jinhong Wang       University of Science and Technology of China

    Reply  Wed Nov 4 14:42:22 2009, Stefan Ritt, outline dimension of DRS4 qfn76.png

Jinhong Wang wrote:

QFN_package.jpg

                                                                                                            Fig.1        typical dimension of QFN package

Above is the typical dimension specification for QFN package. I cann't find the corresponding "T1" as in Fig.1 in the DRS4 documents, nor any of the tolerance of the dimensions, which are usually expressed in the form of  a range between a min. value and a max. value.

So will you specify the dimension of "T1" and "W1", and the dimension tolerance of them?

Thanks and best wishes!

                                                                               Jinhong Wang       University of Science and Technology of China

 

Please find attached the complete dimensions.

Entry  Mon Dec 14 10:14:16 2009, Jinhong Wang, Trigger of DRS4 

Dear Mr. S. Ritt

     The following is my confusion about the trigger of DRS4. It mainly concertrates on the generation of trigger signal to stop DRS4 sampling process for readout of sampled waveform.

     As metioned in the datasheet of DRS4, the chip samples the analog input every domino sampling period.  After finished sampling a waveform, the sampling process can be stoped by lowering the DWRITE while keeping DENABLE high. But the analog input is asychronous to the Domino CLK.  Then, how can we know when to  stop the domino sampling process to read out the sampled waveform? Of course, a trigger can be used. But from my present knowledge of DRS4, trigger can only be generated from analog input. Analog input is splited into two channels, one to DRS4 analog input, the other to FPGA as the trigger. However, splitting analog inputs increases the system design complexity, and may lower the total performace. So what is your suggestion?

    In our system, there are 8 analog inputs to a signal DRS4 chip, the outputs of DRS4 chip are connected to an 8-channel 14 bit ADC ( AD9252). It wold be kind of you to inform me about the most applicable approach for readout of DRS4 sampled wavefrom.

   Best regards.

   Sincerely,

   Jinhong Wang (wangjinh@mail.ustc.edu.cn)

    Reply  Tue Dec 15 14:38:09 2009, Stefan Ritt, Trigger of DRS4 

Jinhong Wang wrote:

Dear Mr. S. Ritt

     The following is my confusion about the trigger of DRS4. It mainly concertrates on the generation of trigger signal to stop DRS4 sampling process for readout of sampled waveform.

     As metioned in the datasheet of DRS4, the chip samples the analog input every domino sampling period.  After finished sampling a waveform, the sampling process can be stoped by lowering the DWRITE while keeping DENABLE high. But the analog input is asychronous to the Domino CLK.  Then, how can we know when to  stop the domino sampling process to read out the sampled waveform? Of course, a trigger can be used. But from my present knowledge of DRS4, trigger can only be generated from analog input. Analog input is splited into two channels, one to DRS4 analog input, the other to FPGA as the trigger. However, splitting analog inputs increases the system design complexity, and may lower the total performace. So what is your suggestion?

    In our system, there are 8 analog inputs to a signal DRS4 chip, the outputs of DRS4 chip are connected to an 8-channel 14 bit ADC ( AD9252). It wold be kind of you to inform me about the most applicable approach for readout of DRS4 sampled wavefrom.

   Best regards.

   Sincerely,

   Jinhong Wang (wangjinh@mail.ustc.edu.cn)

Indeed you have to make an external trigger. The evaluation board uses the "transparent mode" of the DRS4 to "mirror" the input signal at the output, then puts a comparator there. The schematics of the evaluation board is in the manual. This does then not degrate the analog performance. You can of course also split the signal at the input, this will only add a minor additional load to the input signal, since the load of the DRS4 chips itself is much bigger than that of any comparator.

An alternative is to turn on the transparent mode and continuously digitize all 8 outputs with your AD9252. Then you make the trigger purely digital in your FPGA. You can put there a comparator, or even more complex logic like multiplicity etc. Note however that this causes some latency, since the ADC has a pipeline which is quite long, so you have to buffer the latency of your trigger in the analog window of the DRS4 sampling cells. Like if you run the DRS4 at 1 GSPS, you can accomodate 1024 ns of sampling depth, which is good for maybe 500 ns of trigger latency plus 500 ns of the waveform of interest.

       Reply  Mon Dec 21 10:17:05 2009, Jinhong Wang, Trigger of DRS4 

Stefan Ritt wrote:

Jinhong Wang wrote:

Dear Mr. S. Ritt

     The following is my confusion about the trigger of DRS4. It mainly concertrates on the generation of trigger signal to stop DRS4 sampling process for readout of sampled waveform.

     As metioned in the datasheet of DRS4, the chip samples the analog input every domino sampling period.  After finished sampling a waveform, the sampling process can be stoped by lowering the DWRITE while keeping DENABLE high. But the analog input is asychronous to the Domino CLK.  Then, how can we know when to  stop the domino sampling process to read out the sampled waveform? Of course, a trigger can be used. But from my present knowledge of DRS4, trigger can only be generated from analog input. Analog input is splited into two channels, one to DRS4 analog input, the other to FPGA as the trigger. However, splitting analog inputs increases the system design complexity, and may lower the total performace. So what is your suggestion?

    In our system, there are 8 analog inputs to a signal DRS4 chip, the outputs of DRS4 chip are connected to an 8-channel 14 bit ADC ( AD9252). It wold be kind of you to inform me about the most applicable approach for readout of DRS4 sampled wavefrom.

   Best regards.

   Sincerely,

   Jinhong Wang (wangjinh@mail.ustc.edu.cn)

Indeed you have to make an external trigger. The evaluation board uses the "transparent mode" of the DRS4 to "mirror" the input signal at the output, then puts a comparator there. The schematics of the evaluation board is in the manual. This does then not degrate the analog performance. You can of course also split the signal at the input, this will only add a minor additional load to the input signal, since the load of the DRS4 chips itself is much bigger than that of any comparator.

An alternative is to turn on the transparent mode and continuously digitize all 8 outputs with your AD9252. Then you make the trigger purely digital in your FPGA. You can put there a comparator, or even more complex logic like multiplicity etc. Note however that this causes some latency, since the ADC has a pipeline which is quite long, so you have to buffer the latency of your trigger in the analog window of the DRS4 sampling cells. Like if you run the DRS4 at 1 GSPS, you can accomodate 1024 ns of sampling depth, which is good for maybe 500 ns of trigger latency plus 500 ns of the waveform of interest.

Thank you. The transparent mode can be really helpful. Can you provide me in more details of the chip's transparent mode? I am still confused about the following aspects.

I notice that DRS4 samples the analog wave in the way "clear before write", and in the transparent mode, there will be certain delay before the trigger logic stops the sampling process. So,does it mean that the waveform recording process per Domino sampling cycle will not degrade the amplitude of the analog signal? Hence, for two idential analog inputs, one with a trigger latency of 500 ns and the other of 510 ns, the sampled waveform is identical, what differs is the starting number of the first active sampling cell, where the reading process considered to be started.   Is that right? Looking forward to your insight.

Best regrads.

Sincerely,

         Jinhong Wang (wangjinh@mail.ustc.edu.cn)

          Reply  Mon Dec 21 16:52:08 2009, Stefan Ritt, Trigger of DRS4 

Jinhong Wang wrote:

Stefan Ritt wrote:

Jinhong Wang wrote:

Dear Mr. S. Ritt

     The following is my confusion about the trigger of DRS4. It mainly concertrates on the generation of trigger signal to stop DRS4 sampling process for readout of sampled waveform.

     As metioned in the datasheet of DRS4, the chip samples the analog input every domino sampling period.  After finished sampling a waveform, the sampling process can be stoped by lowering the DWRITE while keeping DENABLE high. But the analog input is asychronous to the Domino CLK.  Then, how can we know when to  stop the domino sampling process to read out the sampled waveform? Of course, a trigger can be used. But from my present knowledge of DRS4, trigger can only be generated from analog input. Analog input is splited into two channels, one to DRS4 analog input, the other to FPGA as the trigger. However, splitting analog inputs increases the system design complexity, and may lower the total performace. So what is your suggestion?

    In our system, there are 8 analog inputs to a signal DRS4 chip, the outputs of DRS4 chip are connected to an 8-channel 14 bit ADC ( AD9252). It wold be kind of you to inform me about the most applicable approach for readout of DRS4 sampled wavefrom.

   Best regards.

   Sincerely,

   Jinhong Wang (wangjinh@mail.ustc.edu.cn)

Indeed you have to make an external trigger. The evaluation board uses the "transparent mode" of the DRS4 to "mirror" the input signal at the output, then puts a comparator there. The schematics of the evaluation board is in the manual. This does then not degrate the analog performance. You can of course also split the signal at the input, this will only add a minor additional load to the input signal, since the load of the DRS4 chips itself is much bigger than that of any comparator.

An alternative is to turn on the transparent mode and continuously digitize all 8 outputs with your AD9252. Then you make the trigger purely digital in your FPGA. You can put there a comparator, or even more complex logic like multiplicity etc. Note however that this causes some latency, since the ADC has a pipeline which is quite long, so you have to buffer the latency of your trigger in the analog window of the DRS4 sampling cells. Like if you run the DRS4 at 1 GSPS, you can accomodate 1024 ns of sampling depth, which is good for maybe 500 ns of trigger latency plus 500 ns of the waveform of interest.

Thank you. The transparent mode can be really helpful. Can you provide me in more details of the chip's transparent mode? I am still confused about the following aspects.

I notice that DRS4 samples the analog wave in the way "clear before write", and in the transparent mode, there will be certain delay before the trigger logic stops the sampling process. So,does it mean that the waveform recording process per Domino sampling cycle will not degrade the amplitude of the analog signal? Hence, for two idential analog inputs, one with a trigger latency of 500 ns and the other of 510 ns, the sampled waveform is identical, what differs is the starting number of the first active sampling cell, where the reading process considered to be started.   Is that right? Looking forward to your insight.

Best regrads.

Sincerely,

         Jinhong Wang (wangjinh@mail.ustc.edu.cn)

The amplitude of the analog signal is not degraded by the transparent mode, since the signal is buffered on the chip, and the output of this buffer is send off the chip. The waveform digitizing of course requires quite some current to charge up all capacitors, so there is  maximum current of ~1mA for 5 GSPS. If you only have a weak signal source, your bandwidth might be limited by that. On the evaluation board for example we use passive transformers to produce the differential input signal from a single-ended signal. Although the transformers are rated 1 GHz Bandwidth, we only achieve 200 MHz with the passive transformers. By using active high speed differential drivers, you can get about 700 MHz right now.

If you have two channels with 500 ns and 510 ns trigger latency, there is no difference in the "domino stop position" since there is only one domino circuit per chip which can be stopped. So the stop position is the same for all eight channels on a chip. 

             Reply  Tue Dec 22 01:30:55 2009, Jinhong Wang, Trigger of DRS4 

Stefan Ritt wrote:

Jinhong Wang wrote:

Stefan Ritt wrote:

Jinhong Wang wrote:

Dear Mr. S. Ritt

     The following is my confusion about the trigger of DRS4. It mainly concertrates on the generation of trigger signal to stop DRS4 sampling process for readout of sampled waveform.

     As metioned in the datasheet of DRS4, the chip samples the analog input every domino sampling period.  After finished sampling a waveform, the sampling process can be stoped by lowering the DWRITE while keeping DENABLE high. But the analog input is asychronous to the Domino CLK.  Then, how can we know when to  stop the domino sampling process to read out the sampled waveform? Of course, a trigger can be used. But from my present knowledge of DRS4, trigger can only be generated from analog input. Analog input is splited into two channels, one to DRS4 analog input, the other to FPGA as the trigger. However, splitting analog inputs increases the system design complexity, and may lower the total performace. So what is your suggestion?

    In our system, there are 8 analog inputs to a signal DRS4 chip, the outputs of DRS4 chip are connected to an 8-channel 14 bit ADC ( AD9252). It wold be kind of you to inform me about the most applicable approach for readout of DRS4 sampled wavefrom.

   Best regards.

   Sincerely,

   Jinhong Wang (wangjinh@mail.ustc.edu.cn)

Indeed you have to make an external trigger. The evaluation board uses the "transparent mode" of the DRS4 to "mirror" the input signal at the output, then puts a comparator there. The schematics of the evaluation board is in the manual. This does then not degrate the analog performance. You can of course also split the signal at the input, this will only add a minor additional load to the input signal, since the load of the DRS4 chips itself is much bigger than that of any comparator.

An alternative is to turn on the transparent mode and continuously digitize all 8 outputs with your AD9252. Then you make the trigger purely digital in your FPGA. You can put there a comparator, or even more complex logic like multiplicity etc. Note however that this causes some latency, since the ADC has a pipeline which is quite long, so you have to buffer the latency of your trigger in the analog window of the DRS4 sampling cells. Like if you run the DRS4 at 1 GSPS, you can accomodate 1024 ns of sampling depth, which is good for maybe 500 ns of trigger latency plus 500 ns of the waveform of interest.

Thank you. The transparent mode can be really helpful. Can you provide me in more details of the chip's transparent mode? I am still confused about the following aspects.

I notice that DRS4 samples the analog wave in the way "clear before write", and in the transparent mode, there will be certain delay before the trigger logic stops the sampling process. So,does it mean that the waveform recording process per Domino sampling cycle will not degrade the amplitude of the analog signal? Hence, for two idential analog inputs, one with a trigger latency of 500 ns and the other of 510 ns, the sampled waveform is identical, what differs is the starting number of the first active sampling cell, where the reading process considered to be started.   Is that right? Looking forward to your insight.

Best regrads.

Sincerely,

         Jinhong Wang (wangjinh@mail.ustc.edu.cn)

The amplitude of the analog signal is not degraded by the transparent mode, since the signal is buffered on the chip, and the output of this buffer is send off the chip. The waveform digitizing of course requires quite some current to charge up all capacitors, so there is  maximum current of ~1mA for 5 GSPS. If you only have a weak signal source, your bandwidth might be limited by that. On the evaluation board for example we use passive transformers to produce the differential input signal from a single-ended signal. Although the transformers are rated 1 GHz Bandwidth, we only achieve 200 MHz with the passive transformers. By using active high speed differential drivers, you can get about 700 MHz right now.

If you have two channels with 500 ns and 510 ns trigger latency, there is no difference in the "domino stop position" since there is only one domino circuit per chip which can be stopped. So the stop position is the same for all eight channels on a chip. 

 So you mean there is an analog buffer per channel? The analog signal is buffered there, before entering the sampling cells? Then, when will the buffer content be released and cleared? How shall I handle "Dwite" and "Denable" during a complete operation when an analog signal arrives in the transparent mode? I cannot find more information beyond the datasheet,  a detailed description of the transparent mode (and the analog buffer, if possible) will be really helpful for me.

Best,

Sincerely,

Jinhong Wang (wangjinh@mail.ustc.edu.cn)

                Reply  Tue Dec 22 09:07:27 2009, Stefan Ritt, Trigger of DRS4 

Jinhong Wang wrote:

Stefan Ritt wrote:

Jinhong Wang wrote:

Stefan Ritt wrote:

Jinhong Wang wrote:

Dear Mr. S. Ritt

     The following is my confusion about the trigger of DRS4. It mainly concertrates on the generation of trigger signal to stop DRS4 sampling process for readout of sampled waveform.

     As metioned in the datasheet of DRS4, the chip samples the analog input every domino sampling period.  After finished sampling a waveform, the sampling process can be stoped by lowering the DWRITE while keeping DENABLE high. But the analog input is asychronous to the Domino CLK.  Then, how can we know when to  stop the domino sampling process to read out the sampled waveform? Of course, a trigger can be used. But from my present knowledge of DRS4, trigger can only be generated from analog input. Analog input is splited into two channels, one to DRS4 analog input, the other to FPGA as the trigger. However, splitting analog inputs increases the system design complexity, and may lower the total performace. So what is your suggestion?

    In our system, there are 8 analog inputs to a signal DRS4 chip, the outputs of DRS4 chip are connected to an 8-channel 14 bit ADC ( AD9252). It wold be kind of you to inform me about the most applicable approach for readout of DRS4 sampled wavefrom.

   Best regards.

   Sincerely,

   Jinhong Wang (wangjinh@mail.ustc.edu.cn)

Indeed you have to make an external trigger. The evaluation board uses the "transparent mode" of the DRS4 to "mirror" the input signal at the output, then puts a comparator there. The schematics of the evaluation board is in the manual. This does then not degrate the analog performance. You can of course also split the signal at the input, this will only add a minor additional load to the input signal, since the load of the DRS4 chips itself is much bigger than that of any comparator.

An alternative is to turn on the transparent mode and continuously digitize all 8 outputs with your AD9252. Then you make the trigger purely digital in your FPGA. You can put there a comparator, or even more complex logic like multiplicity etc. Note however that this causes some latency, since the ADC has a pipeline which is quite long, so you have to buffer the latency of your trigger in the analog window of the DRS4 sampling cells. Like if you run the DRS4 at 1 GSPS, you can accomodate 1024 ns of sampling depth, which is good for maybe 500 ns of trigger latency plus 500 ns of the waveform of interest.

Thank you. The transparent mode can be really helpful. Can you provide me in more details of the chip's transparent mode? I am still confused about the following aspects.

I notice that DRS4 samples the analog wave in the way "clear before write", and in the transparent mode, there will be certain delay before the trigger logic stops the sampling process. So,does it mean that the waveform recording process per Domino sampling cycle will not degrade the amplitude of the analog signal? Hence, for two idential analog inputs, one with a trigger latency of 500 ns and the other of 510 ns, the sampled waveform is identical, what differs is the starting number of the first active sampling cell, where the reading process considered to be started.   Is that right? Looking forward to your insight.

Best regrads.

Sincerely,

         Jinhong Wang (wangjinh@mail.ustc.edu.cn)

The amplitude of the analog signal is not degraded by the transparent mode, since the signal is buffered on the chip, and the output of this buffer is send off the chip. The waveform digitizing of course requires quite some current to charge up all capacitors, so there is  maximum current of ~1mA for 5 GSPS. If you only have a weak signal source, your bandwidth might be limited by that. On the evaluation board for example we use passive transformers to produce the differential input signal from a single-ended signal. Although the transformers are rated 1 GHz Bandwidth, we only achieve 200 MHz with the passive transformers. By using active high speed differential drivers, you can get about 700 MHz right now.

If you have two channels with 500 ns and 510 ns trigger latency, there is no difference in the "domino stop position" since there is only one domino circuit per chip which can be stopped. So the stop position is the same for all eight channels on a chip. 

 So you mean there is an analog buffer per channel? The analog signal is buffered there, before entering the sampling cells? Then, when will the buffer content be released and cleared? How shall I handle "Dwite" and "Denable" during a complete operation when an analog signal arrives in the transparent mode? I cannot find more information beyond the datasheet,  a detailed description of the transparent mode (and the analog buffer, if possible) will be really helpful for me.

Best,

Sincerely,

Jinhong Wang (wangjinh@mail.ustc.edu.cn)

There is one analog buffer per channel at the output, as indicated on the FUNCTIONAL BLOCK DIAGRAM of the datasheet. The section ANALOG INPUTS clearly states that the input signal has to load directly the sampling capacitors.

All other people using the chip so far correctly understood these things so far, so I believe more information beyond the datasheet is not necessary. I believe you have a principal problem of understanding, which can hardly be clarified by email. Best would be if you directly call me, I can then explain things to you.

Entry  Wed Dec 30 14:28:33 2009, aliyilmaz, normal_mode_in_drs_exam.cpp 

 Dear Mr. S. Ritt

       i am Ms. student , am working with your DRS4 board to calculate the time of flight of the cosmic particle which passes trough  the hodoscope . i see the signals at scope , which is negative (i don't want to take positive side of the signal).

       i am using your drs_exap.cpp file to  take the data, i set the analog trigger source , threshold level is negative, like this(b->SetTriggerLevel(-30, true) ); but the exam file also registers the positive side of signal (i think  that is spike or internal reflection), is it possible to eliminate this spike? Also i want to register  the data just after the threshold value, but that is always triggered, i think that caused from the mode. Is it possible to set the trigger mode to normal in exam file?,and  how can i do that?

 

Best regards.

Sincerely,

 Ali YILMAZ (ali.yilmaz@roma1.infn.it)

    Reply  Mon Jan 11 16:32:21 2010, Stefan Ritt, normal_mode_in_drs_exam.cpp 

aliyilmaz wrote:

 Dear Mr. S. Ritt

       i am Ms. student , am working with your DRS4 board to calculate the time of flight of the cosmic particle which passes trough  the hodoscope . i see the signals at scope , which is negative (i don't want to take positive side of the signal).

       i am using your drs_exap.cpp file to  take the data, i set the analog trigger source , threshold level is negative, like this(b->SetTriggerLevel(-30, true) ); but the exam file also registers the positive side of signal (i think  that is spike or internal reflection), is it possible to eliminate this spike? Also i want to register  the data just after the threshold value, but that is always triggered, i think that caused from the mode. Is it possible to set the trigger mode to normal in exam file?,and  how can i do that?

 

 

Best regards.

Sincerely,

 Ali YILMAZ (ali.yilmaz@roma1.infn.it)

 

Please note that SetTriggerLevel(level, polarity) needs "level" in volts, not millivolts, so you need SetTriggerLevel(-0.3, true). The trigger mode is not specified with any library call, but depends on what your program does. If you always poll on IsBusy(), then you are already in "normal" mode. The auto mode can only be achieved on the user application level by doing an "artifical" trigger by calling SoftTrigger() if there are no hardware triggers for a certain time. 

Entry  Sun Jan 31 23:52:15 2010, Hao Huan, Failure In Flashing Xilinx PROM 

Hi Stefan,

    I have an old-version DRS4 evaluation board which doesn't have the latest firmware. I tried to flash the drs_eval1.ipf boundary scan chain into the XCF02S PROM with Xilinx IMPACT, and the firmware seemed to go through into the PROM. However, when I started the DRS command line interface to test the firmware it kept on reporting errors like

musb_write: requested 10, wrote -116, errno 0 (No error)

musb_read error -116

musb_write: requested 10, wrote -22, error 0 (No error)

musb_read error -116

and so on. Finally the program made a dumb recognition of the board as

Found mezz. board 0 on USB, serial #0, firmware revision 0

Do you have any idea which caused this problem? Thanks!

    Reply  Mon Feb 1 08:30:42 2010, Stefan Ritt, Failure In Flashing Xilinx PROM DRS.cppDRS.hdrs4_eval1.mcs

Hao Huan wrote:

Hi Stefan,

    I have an old-version DRS4 evaluation board which doesn't have the latest firmware. I tried to flash the drs_eval1.ipf boundary scan chain into the XCF02S PROM with Xilinx IMPACT, and the firmware seemed to go through into the PROM. However, when I started the DRS command line interface to test the firmware it kept on reporting errors like

musb_write: requested 10, wrote -116, errno 0 (No error)

musb_read error -116

musb_write: requested 10, wrote -22, error 0 (No error)

musb_read error -116

and so on. Finally the program made a dumb recognition of the board as

Found mezz. board 0 on USB, serial #0, firmware revision 0

Do you have any idea which caused this problem? Thanks!

A firmware update requires a power cycle of the evaluation board. Have you tried that? I attached for you reference the current drs_eval1.mcs file, which is meant to go into the XCF02S PROM. There were recent changes also in the DRS library, and I'm not sure if yous if recent enough. So I put also the current C files which go with the firmware. They contain also some improvements which should reduce the intrinsic noise of the board.  

Entry  Wed Feb 10 02:57:55 2010, pepe sanchez lopez, Hello 

hello i am an student and i want to do my final project with drs4 board and i really can´t find how to open waveform file and how can i save or opened many of them quickly.

if you can tell me how i will be very grateful.

thanks,

kind regards.

    Reply  Wed Feb 10 15:35:09 2010, Stefan Ritt, Hello 

pepe sanchez lopez wrote:

hello i am an student and i want to do my final project with drs4 board and i really can´t find how to open waveform file and how can i save or opened many of them quickly.

if you can tell me how i will be very grateful.

thanks,

kind regards.

There is no built-in possibility to open waveform files, you have to write your own programs to do that. 

Entry  Mon Feb 15 19:43:34 2010, Ron Grazioso, Problem reading oscilloscope binary waveform output test_pulse.pngpulse_IDL.png

I have saved some waveforms using the oscilloscope application in both binary and xml.  I can see that the xml file gives me proper data values but when I try to read the binary file using IDL, it does not seem correct.  This is a screen shot of the pulse I saved: test_pulse.png

But when I open the binary file in IDL using:

data = uintarr(1024)       ;unsigned integer array
readu,lun1,data
free_lun,lun1
close,lun1

;Convert bits to Volts
data=data*0.000015259-0.5        

window,0,xs=512,ys=512
plot,data[*]

I get: pulse_IDL.png

It looks like the pulse is there but there is something corrupting the data only in binary form.  Is there a setting that may not be correct?

Thanks, Ron

 

 

 

    Reply  Tue Feb 16 09:38:59 2010, Stefan Ritt, Problem reading oscilloscope binary waveform output 

Ron Grazioso wrote:

It looks like the pulse is there but there is something corrupting the data only in binary form.  Is there a setting that may not be correct?

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

Entry  Sun Feb 21 13:41:35 2010, Stefan Ritt, Real Time Conference 2010 

Hello,

may I draw your attention to the upcoming Real Time Conference 2010, taking place in Lisbon, Portugal, May 23rd to May 28th, 2010.

http://rt2010.ipfn.ist.utl.pt/

Several groups which are developing DRS4 electronics will come to this conference and present their work, so it will be a good opportunity to exchange ideas and experiences. There will also be a short course on digital pulse shape processing, which is highly relevant for our field.

Looking forward to see you in Lisbon,

    Stefan 

Entry  Sat Feb 20 01:56:05 2010, Hao Huan, PLLLCK signal of DRS4 

Hi Stefan,

    in the latest DRS4 datasheet I only saw your data of the DRS4 PLL locking time for 6GSPS sampling speed, with other rows "TBD". Have you tried those lower frequencies? According to the datasheet I think the PLLLCK should be stabily low when the PLL is locked; am I right? However when I try my design with the DRS4 chip and feed the reference clock signal at 0.5MHz or 2MHz, the PLLLCK I get can never stabilize. There could be some problem in the PCB circuit connection, but I want to confirm with you since I'm confused with those "TBD" blanks.

    Thanks a lot!

 

    Reply  Sat Feb 20 09:54:48 2010, Stefan Ritt, PLLLCK signal of DRS4 start_1ghz.png

Hao Huan wrote:

Hi Stefan,

    in the latest DRS4 datasheet I only saw your data of the DRS4 PLL locking time for 6GSPS sampling speed, with other rows "TBD". Have you tried those lower frequencies? According to the datasheet I think the PLLLCK should be stabily low when the PLL is locked; am I right? However when I try my design with the DRS4 chip and feed the reference clock signal at 0.5MHz or 2MHz, the PLLLCK I get can never stabilize. There could be some problem in the PCB circuit connection, but I want to confirm with you since I'm confused with those "TBD" blanks.

    Thanks a lot!

 

The locking time is typically 20-30 cycles of the external reference clock, I will update the numbers in the datasheet soon. I attached a screenshot of the chip when starting up at 1 GHz (0.5 MHz REFCLK), so you can see the behaviour. The upper curver is the DTAP signal, the lower curve the PLLLCK signal. As you can see, the PLLLCK signal is not purely digital. Actually it's a simple XOR between the REFCLK and the DTAP signal, so you need an external 4.7nF capacitor to "integrate" this signal. Without this capacitor, you would see small negative spikes whenever there is s small phase shift between the DTAP and the REFCLK signal. Have a look at your DTAP signal, is it in phase with the REFCLK? 

       Reply  Sun Feb 21 00:46:01 2010, Hao Huan, PLLLCK signal of DRS4 

Stefan Ritt wrote:

Hao Huan wrote:

Hi Stefan,

    in the latest DRS4 datasheet I only saw your data of the DRS4 PLL locking time for 6GSPS sampling speed, with other rows "TBD". Have you tried those lower frequencies? According to the datasheet I think the PLLLCK should be stabily low when the PLL is locked; am I right? However when I try my design with the DRS4 chip and feed the reference clock signal at 0.5MHz or 2MHz, the PLLLCK I get can never stabilize. There could be some problem in the PCB circuit connection, but I want to confirm with you since I'm confused with those "TBD" blanks.

    Thanks a lot!

 

The locking time is typically 20-30 cycles of the external reference clock, I will update the numbers in the datasheet soon. I attached a screenshot of the chip when starting up at 1 GHz (0.5 MHz REFCLK), so you can see the behaviour. The upper curver is the DTAP signal, the lower curve the PLLLCK signal. As you can see, the PLLLCK signal is not purely digital. Actually it's a simple XOR between the REFCLK and the DTAP signal, so you need an external 4.7nF capacitor to "integrate" this signal. Without this capacitor, you would see small negative spikes whenever there is s small phase shift between the DTAP and the REFCLK signal. Have a look at your DTAP signal, is it in phase with the REFCLK? 

Thanks! I see. The capacitor is important. However I'm a little confused... If PLLLCK=DTAP XOR REFCLK, shouldn't it integrate to low instead of high when the two clocks are in phase? I must have some misunderstanding here. So if we ignore any realistic complexity and assume DTAP is perfectly locked with REFCLK, will PLLLCK be always low or high? I'm sorry I do not know how the DRS internal PLL and its input/output work...

          Reply  Sun Feb 21 13:47:03 2010, Stefan Ritt, PLLLCK signal of DRS4 

Hao Huan wrote:


Thanks! I see. The capacitor is important. However I'm a little confused... If PLLLCK=DTAP XOR REFCLK, shouldn't it integrate to low instead of high when the two clocks are in phase? I must have some misunderstanding here. So if we ignore any realistic complexity and assume DTAP is perfectly locked with REFCLK, will PLLLCK be always low or high? I'm sorry I do not know how the DRS internal PLL and its input/output work...

Actually the XOR is followed by an inverter, so it will integrate to high if the two clocks are in phase. 

             Reply  Sun Feb 21 20:27:46 2010, Hao Huan, PLLLCK signal of DRS4 

Stefan Ritt wrote:

Hao Huan wrote:


Thanks! I see. The capacitor is important. However I'm a little confused... If PLLLCK=DTAP XOR REFCLK, shouldn't it integrate to low instead of high when the two clocks are in phase? I must have some misunderstanding here. So if we ignore any realistic complexity and assume DTAP is perfectly locked with REFCLK, will PLLLCK be always low or high? I'm sorry I do not know how the DRS internal PLL and its input/output work...

Actually the XOR is followed by an inverter, so it will integrate to high if the two clocks are in phase. 

 Got it. Thank you! By the way I have another question: when the default operation mode of the DRS4 chip is used, i.e. WSRIN is fed internally to WSROUT, at the external pins is it necessary to leave the WSRIN open? Or any input through the pin will not affect the Domino wave running? Also I observe that WSROUT will be always low when the chip is running in this mode; is it the supposed behavior?

                Reply  Sun Feb 21 20:33:57 2010, Stefan Ritt, PLLLCK signal of DRS4 

Hao Huan wrote:

By the way I have another question: when the default operation mode of the DRS4 chip is used, i.e. WSRIN is fed internally to WSROUT, at the external pins is it necessary to leave the WSRIN open? Or any input through the pin will not affect the Domino wave running? Also I observe that WSROUT will be always low when the chip is running in this mode; is it the supposed behavior?

If the WSRin is fed internally to WSROUT, then the level of the WSRIN pin does not matter, it's just disconnected. You can leave the pin open without problem. WSROUT is however active, so you can observe the internal state of the write shift register. In the default configuration (8x1024 sampling cells), all 8 channels are active all the time, so the WSR is loaded with ones. The inverter at the output then makes all zeros from this. If you configure the chip as 4x2048 cells, then you will observe switching bits at WSROUT. 

                   Reply  Mon Feb 22 17:23:59 2010, Hao Huan, PLLLCK signal of DRS4 

Stefan Ritt wrote:

Hao Huan wrote:

By the way I have another question: when the default operation mode of the DRS4 chip is used, i.e. WSRIN is fed internally to WSROUT, at the external pins is it necessary to leave the WSRIN open? Or any input through the pin will not affect the Domino wave running? Also I observe that WSROUT will be always low when the chip is running in this mode; is it the supposed behavior?

If the WSRin is fed internally to WSROUT, then the level of the WSRIN pin does not matter, it's just disconnected. You can leave the pin open without problem. WSROUT is however active, so you can observe the internal state of the write shift register. In the default configuration (8x1024 sampling cells), all 8 channels are active all the time, so the WSR is loaded with ones. The inverter at the output then makes all zeros from this. If you configure the chip as 4x2048 cells, then you will observe switching bits at WSROUT. 

 Sorry; WSROUT also has an inverter? Actually I have one more stupid question about the shift registers: when we assert the address bits to operate on one shift register, e.g. WSR, we use SRIN to give input and SROUT to read output; but how does the shift register know whether we're reading or writing? Or it will just receive input from SRIN and give output at SROUT at the same time?

Thank you so much!

                      Reply  Wed Mar 3 14:37:40 2010, Stefan Ritt, PLLLCK signal of DRS4 

Hao Huan wrote:

Stefan Ritt wrote:

Hao Huan wrote:

By the way I have another question: when the default operation mode of the DRS4 chip is used, i.e. WSRIN is fed internally to WSROUT, at the external pins is it necessary to leave the WSRIN open? Or any input through the pin will not affect the Domino wave running? Also I observe that WSROUT will be always low when the chip is running in this mode; is it the supposed behavior?

If the WSRin is fed internally to WSROUT, then the level of the WSRIN pin does not matter, it's just disconnected. You can leave the pin open without problem. WSROUT is however active, so you can observe the internal state of the write shift register. In the default configuration (8x1024 sampling cells), all 8 channels are active all the time, so the WSR is loaded with ones. The inverter at the output then makes all zeros from this. If you configure the chip as 4x2048 cells, then you will observe switching bits at WSROUT. 

 Sorry; WSROUT also has an inverter? Actually I have one more stupid question about the shift registers: when we assert the address bits to operate on one shift register, e.g. WSR, we use SRIN to give input and SROUT to read output; but how does the shift register know whether we're reading or writing? Or it will just receive input from SRIN and give output at SROUT at the same time?

Actually I double checked the schematics, WSROUT has NO inverter at the output. So the output should be always one in a 8x1024 channel configuration.

Concerning the read/write you are right. On each clock cycle, SRIN will be shifted into the first bit, and the last bit will be visible at SROUT.

Entry  Wed Mar 3 17:36:31 2010, Hao Huan, Initialization of the Domino Circuit 

Hi Stefan,

    I read in the datasheet that every time after power up the Domino wave in DRS4 needs to be started and stopped once to initialize the Domino circuit. However in your firmware it seems the chip immediately goes into the idle state after reset. Is that Domino circuit initialization really necessary?

    Also an aside question: in your firmware the readout process has the SRCLK sent to DRS4 only about 200ns later after RSRLOAD gets asserted instead of immediately following RSRLOAD. Is there any reason for that?

    Thanks a lot!

 

    Reply  Wed Mar 3 17:49:30 2010, Stefan Ritt, Initialization of the Domino Circuit 

Hao Huan wrote:

Hi Stefan,

    I read in the datasheet that every time after power up the Domino wave in DRS4 needs to be started and stopped once to initialize the Domino circuit. However in your firmware it seems the chip immediately goes into the idle state after reset. Is that Domino circuit initialization really necessary?

    Also an aside question: in your firmware the readout process has the SRCLK sent to DRS4 only about 200ns later after RSRLOAD gets asserted instead of immediately following RSRLOAD. Is there any reason for that?

    Thanks a lot!

 

The start/stop requirement is obsolete and has been replaced by  elog:10. I need to update this in the datasheet. The delay between the RSRLOAD and the SRCLK has the following reason: On the RSRLOAD the first sampling cell is output to the chip and to the ADC. This can sometimes be a rather high swing, which needs some time to settle, and some warm-up for the output driver. But actually I never really measured it, so it's there just as a safety margin. But I would encourage you to try to reduce this time and see it the first few bins of the readout change in offset.

Entry  Thu Mar 4 19:14:10 2010, Hao Huan, Readout of DRS Data 

Hi Stefan,

    thanks to your help I can now successfully keep the Domino wave running at a stable frequency and maintain the channel cascading information in the Write Shift Register. (Since you told me WSR always reads and writes at the same time, I think I need to rewrite the information back every time after reading out from WSR to decide from which channel my data come, don't I?)

    However I'm still having difficulty in reading out from the DRS cells. I use the ROI readout mode and assume as long as I give a pulse on RSRLOAD the data will come out one by one. However, what I get is just a constant with some noise, which seems I'm always reading from the same cell. Actually I'm not very clear about how it works. What's the mechanism for RSRLOAD  and do I have to initialize the Read Shift Register to use the ROI mode? Also I read in the datasheet that WSROUT will give RSR output when DWRITE is low. Sometimes I see some random bits from this output and sometimes I see all zero's. What is the reasonable output I should see from WSROUT, say, when I'm running in the transparent mode with DWRITE low?

    Thank you very much!

 

    Reply  Fri Mar 5 23:29:04 2010, Hao Huan, Readout of DRS Data 

Hao Huan wrote:

Hi Stefan,

    thanks to your help I can now successfully keep the Domino wave running at a stable frequency and maintain the channel cascading information in the Write Shift Register. (Since you told me WSR always reads and writes at the same time, I think I need to rewrite the information back every time after reading out from WSR to decide from which channel my data come, don't I?)

    However I'm still having difficulty in reading out from the DRS cells. I use the ROI readout mode and assume as long as I give a pulse on RSRLOAD the data will come out one by one. However, what I get is just a constant with some noise, which seems I'm always reading from the same cell. Actually I'm not very clear about how it works. What's the mechanism for RSRLOAD  and do I have to initialize the Read Shift Register to use the ROI mode? Also I read in the datasheet that WSROUT will give RSR output when DWRITE is low. Sometimes I see some random bits from this output and sometimes I see all zero's. What is the reasonable output I should see from WSROUT, say, when I'm running in the transparent mode with DWRITE low?

    Thank you very much!

 

Hi Stefan,

    I tried again and confirmed the problem... In the full readout mode I could successfully read out all the data, but in the ROI mode if I naively apply a pulse at RSRLOAD the results are not right. Is there anything I should be careful about in the ROI readout mode?

    Thanks!

 

    Reply  Thu Mar 11 11:45:52 2010, Stefan Ritt, Readout of DRS Data 

Hao Huan wrote:

Hi Stefan,

    thanks to your help I can now successfully keep the Domino wave running at a stable frequency and maintain the channel cascading information in the Write Shift Register. (Since you told me WSR always reads and writes at the same time, I think I need to rewrite the information back every time after reading out from WSR to decide from which channel my data come, don't I?)

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.

Hao Huan wrote:

    However I'm still having difficulty in reading out from the DRS cells. I use the ROI readout mode and assume as long as I give a pulse on RSRLOAD the data will come out one by one. 

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. 

Hao Huan wrote:

Also I read in the datasheet that WSROUT will give RSR output when DWRITE is low. Sometimes I see some random bits from this output and sometimes I see all zero's. What is the reasonable output I should see from WSROUT, say, when I'm running in the transparent mode with DWRITE low? 

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.

 

Entry  Thu Mar 11 21:37:32 2010, Hao Huan, Input Bandwidth of the DRS Chip 

Hi Stefan,

    I read in the DRS datasheet that the input bandwidth if 950MHz. However, it also says the output bandwidth in the transparent mode is 50MHz. Since in the transparent mode the input is routed to the output, does it mean the input bandwidth also gets reduced in the transparent mode? I don't know how the transparent mode works inside the chip of course, but this value would be important since if the hardware discriminators are connected to the output of DRS, we have to always work in the transparent mode.

    Thanks!

 

    Reply  Fri Mar 12 08:04:44 2010, Stefan Ritt, Input Bandwidth of the DRS Chip 

Hao Huan wrote:

I read in the DRS datasheet that the input bandwidth if 950MHz. However, it also says the output bandwidth in the transparent mode is 50MHz. Since in the transparent mode the input is routed to the output, does it mean the input bandwidth also gets reduced in the transparent mode? I don't know how the transparent mode works inside the chip of course, but this value would be important since if the hardware discriminators are connected to the output of DRS, we have to always work in the transparent mode.

In transparent mode, the input signal also gets routed to the output, where it goes through an output buffer, which limits the bandwidth to about 50 MHz, but only for the output. The effective bandwidth to the sampling cells is not changed. Please note however that the 950 MHz are for the "chip only". We measured this by keeping the input amplitude from a function generator constant at the input pin of the chip (measured with a high speed oscilloscope). Since each signal source has a non-zero impedance, the signal tends to "shrink" at high bandwidth, and we had to adjust the level of the function generator to keep the amplitude constant at high frequencies. If you do a realistic input stage with the THS4508 for example, the achievable bandwidth will be around 800 MHz.

Entry  Tue Mar 9 23:28:45 2010, Hao Huan, Serial Interface Frequency of the DRS Chip 

Hi Stefan,

    in the DRS4 datasheet I read that the optimal frequency for SRCLK is 33MHz. However in the evaluation board firmware SRCLK is toggled at rising edges of the internal 33MHz clock, i.e. the frequency of SRCLK itself is 16.5MHz instead. Is that frequency better than 33MHz?

    Thanks!

 

    Reply  Wed Mar 10 10:07:28 2010, Stefan Ritt, Serial Interface Frequency of the DRS Chip 

Hao Huan wrote:

in the DRS4 datasheet I read that the optimal frequency for SRCLK is 33MHz. However in the evaluation board firmware SRCLK is toggled at rising edges of the internal 33MHz clock, i.e. the frequency of SRCLK itself is 16.5MHz instead. Is that frequency better than 33MHz?

The reason for the 16.5 MHz is the following:

After each block of 32 bins, the DRS4 chip switches an internal segment, which causes some small spike at the analog output of the chip. This spike is a bit wider than 30ns, so if everything is digitized with 33 MHz, then you see small spiked each 32 cells. The appropriate solution would be to modify the firmware to digitize all cells with 30ns (33 MHz) and all cells with the spike with ~50 ns (20 MHz). If you do the ROI readout mode, you don't know for the first 10 cells if one of them belong to this class, since the cell address takes 10 cycles to be read out. So you would first have to read 10 cells, and then if you realize that one of them is one of the problematic ones (cell number modulo 32 is zero), you have to re-read the first 10 cells, and digitize the problematic cell with a longer settling time. Now this is a bit complicated to implement in the firmware, so I was just too lazy to do it and decided to digitize everything with 16.5 MHz. But if you are worried about the dead time, you should consider implementing the mentioned algorithm. 

       Reply  Thu Mar 18 21:38:10 2010, Hao Huan, Serial Interface Frequency of the DRS Chip 

Stefan Ritt wrote:

Hao Huan wrote:

in the DRS4 datasheet I read that the optimal frequency for SRCLK is 33MHz. However in the evaluation board firmware SRCLK is toggled at rising edges of the internal 33MHz clock, i.e. the frequency of SRCLK itself is 16.5MHz instead. Is that frequency better than 33MHz?

The reason for the 16.5 MHz is the following:

After each block of 32 bins, the DRS4 chip switches an internal segment, which causes some small spike at the analog output of the chip. This spike is a bit wider than 30ns, so if everything is digitized with 33 MHz, then you see small spiked each 32 cells. The appropriate solution would be to modify the firmware to digitize all cells with 30ns (33 MHz) and all cells with the spike with ~50 ns (20 MHz). If you do the ROI readout mode, you don't know for the first 10 cells if one of them belong to this class, since the cell address takes 10 cycles to be read out. So you would first have to read 10 cells, and then if you realize that one of them is one of the problematic ones (cell number modulo 32 is zero), you have to re-read the first 10 cells, and digitize the problematic cell with a longer settling time. Now this is a bit complicated to implement in the firmware, so I was just too lazy to do it and decided to digitize everything with 16.5 MHz. But if you are worried about the dead time, you should consider implementing the mentioned algorithm. 

 Thanks! The suggested algorithm looks promising. However, if the spikes take place only for those specific cells, is it possible to absorb them into the offset calibration?

          Reply  Thu Mar 18 22:10:41 2010, Stefan Ritt, Serial Interface Frequency of the DRS Chip 

Hao Huan wrote:

 

 Thanks! The suggested algorithm looks promising. However, if the spikes take place only for those specific cells, is it possible to absorb them into the offset calibration?

No, since they are not constant. The bus segments charge up between readouts with a time constant of about 0.5s. So if you do the readout with 1Hz event rate and with 100Hz event rate, the peaks will differ by a factor up to 10, so a constant offset correction cannot take care of that.

Entry  Sun Mar 21 02:03:44 2010, Hao Huan, PLL Loop Filter Configuration 

Hi Stefan,

    in the datasheet it says at 6GSPS the typical loop filter parameters are 220Ω, 2.2nF and 27nF. If I want to run the Domino wave nominally at 1GHz, i.e. with a reference clock frequency around 0.5MHz, is there any recommended loop filter configuration? Is the setup of the evaluation board, that is, 220Ω, 3.3nF and 33nF an optimal choice?

    Thank you very much.

 

    Reply  Mon Mar 22 09:12:19 2010, Stefan Ritt, PLL Loop Filter Configuration 

Hao Huan wrote:

in the datasheet it says at 6GSPS the typical loop filter parameters are 220Ω, 2.2nF and 27nF. If I want to run the Domino wave nominally at 1GHz, i.e. with a reference clock frequency around 0.5MHz, is there any recommended loop filter configuration? Is the setup of the evaluation board, that is, 220Ω, 3.3nF and 33nF an optimal choice?

The setup of the evaluation board is a good compromise which runs between 1 GHz and 5 GHz. Unfortunately I never found the time to investigate this in more detail. So if someone is willing to measure settling time and phase jitter with various combinations of R, C1 and C2, I'm more than happy to include this into the datasheet. 

Entry  Tue Apr 13 10:45:18 2010, lorenzo neri, evaluation board used like a counter 

Hi all



it is possible to use the evaluation board like a counter?



I'm interested in the arriving time of all self trigger event in to a channel.



the input signal are 2V TTL of 10 ns at 50ohm, and the time acquisition window is 1 second.




can someone help me?



thanks in advance,



Lorenzo

    Reply  Tue Apr 13 13:12:43 2010, Stefan Ritt, evaluation board used like a counter 

lorenzo neri wrote:

Hi all

it is possible to use the evaluation board like a counter?

I'm interested in the arriving time of all self trigger event in to a channel.

the input signal are 2V TTL of 10 ns at 50ohm, and the time acquisition window is 1 second.

The evaluation board is as good or bad as an digital oscilloscope to work like a counter. At 1 GSPS, you have a window of one microsecond, which is certainly too short for your application. 

Entry  Fri Apr 9 17:14:45 2010, Hao Huan, Baseline Variation In Data 

Hi Stefan,

    when I sample a constant input with the DRS 4 chip, there was a baseline variation showing up as a saw-tooth pattern which grows with the absolute value of the differential input. Do you think this is the kind of baseline variation mentioned in the evaluation board manual, i.e. coming from clock jitter in ADC sampling?

    Thanks a lot!

 

    Reply  Tue Apr 13 13:56:07 2010, Stefan Ritt, Baseline Variation In Data 

Hao Huan wrote:

Hi Stefan,

    when I sample a constant input with the DRS 4 chip, there was a baseline variation showing up as a saw-tooth pattern which grows with the absolute value of the differential input. Do you think this is the kind of baseline variation mentioned in the evaluation board manual, i.e. coming from clock jitter in ADC sampling?

    Thanks a lot!

 

Please post an oscilloscope screenshot here and I can tell you. 

Entry  Tue Apr 28 11:44:07 2009, Stefan Ritt, Simple example application to read a DRS evaluation board drs_exam.cpp

Several people asked for s simple application to guide them in writing their own application to read out a DRS board. Such an application has been added in software revions 2.1.1 and is attached to this message. This example program drs_exam.cpp written in C++ does the following necessary steps to access a DRS board:

  • Crate a "DRS" object and scan all USB devices
  • Display found DRS boards
  • Initialize the first found board and set the sampling frequency to 5 GSPS
  • Enable internal trigger on channel #1 with 250 mV threshold
  • Start acquisition and wait for a trigger
  • Read two waveforms (both time and amplitude)
  • Repeat this 10 times

I know that we are still missing a good documentation for the DRS API, but I have not yet found the time to do that. I hope the example program is enough for most people to start writing own programs. For Windows users (MS Visual C++ 8.0) there is a drs.sln project file, and for linux users there is a Makefile which can be used to compile this example program.

 

    Reply  Wed Apr 29 07:57:33 2009, Stefan Ritt, Simple example application to read a DRS evaluation board DRS.cppDRS.h

 

Stefan Ritt wrote:

Several people asked for s simple application to guide them in writing their own application to read out a DRS board. Such an application has been added in software revions 2.1.1 and is attached to this message. This example program drs_exam.cpp written in C++ does the following necessary steps to access a DRS board:

  • Crate a "DRS" object and scan all USB devices
  • Display found DRS boards
  • Initialize the first found board and set the sampling frequency to 5 GSPS
  • Enable internal trigger on channel #1 with 250 mV threshold
  • Start acquisition and wait for a trigger
  • Read two waveforms (both time and amplitude)
  • Repeat this 10 times

I know that we are still missing a good documentation for the DRS API, but I have not yet found the time to do that. I hope the example program is enough for most people to start writing own programs. For Windows users (MS Visual C++ 8.0) there is a drs.sln project file, and for linux users there is a Makefile which can be used to compile this example program.

 

 

One note: The program drs_exam.cpp published in the previous message needs the current version of the DRS library in DRS.cpp and DRS.h. They are contained in the software release 2.1.1 which has to be downloaded. For simplicity, I attached the two files to this message.

    Reply  Mon Apr 5 17:57:41 2010, Heejong Kim, Simple example application to read a DRS evaluation board 

Stefan Ritt wrote:

Several people asked for s simple application to guide them in writing their own application to read out a DRS board. Such an application has been added in software revions 2.1.1 and is attached to this message. This example program drs_exam.cpp written in C++ does the following necessary steps to access a DRS board:

  • Crate a "DRS" object and scan all USB devices
  • Display found DRS boards
  • Initialize the first found board and set the sampling frequency to 5 GSPS
  • Enable internal trigger on channel #1 with 250 mV threshold
  • Start acquisition and wait for a trigger
  • Read two waveforms (both time and amplitude)
  • Repeat this 10 times

I know that we are still missing a good documentation for the DRS API, but I have not yet found the time to do that. I hope the example program is enough for most people to start writing own programs. For Windows users (MS Visual C++ 8.0) there is a drs.sln project file, and for linux users there is a Makefile which can be used to compile this example program.

 

 Hi, Stefan,

drs_exam.cpp is working good to read-out one board.

Now I would like to read-out two boards at the same time using the same trigger( external or internal).

I'm trying to understand and modify the original code for control two board.

Meantime, it would be very appreciated if you give any tips for this.

Thanks,

Heejong

       Reply  Tue Apr 13 14:15:16 2010, Stefan Ritt, Simple example application to read a DRS evaluation board 

Heejong Kim wrote:

Stefan Ritt wrote:

Several people asked for s simple application to guide them in writing their own application to read out a DRS board. Such an application has been added in software revions 2.1.1 and is attached to this message. This example program drs_exam.cpp written in C++ does the following necessary steps to access a DRS board:

  • Crate a "DRS" object and scan all USB devices
  • Display found DRS boards
  • Initialize the first found board and set the sampling frequency to 5 GSPS
  • Enable internal trigger on channel #1 with 250 mV threshold
  • Start acquisition and wait for a trigger
  • Read two waveforms (both time and amplitude)
  • Repeat this 10 times

I know that we are still missing a good documentation for the DRS API, but I have not yet found the time to do that. I hope the example program is enough for most people to start writing own programs. For Windows users (MS Visual C++ 8.0) there is a drs.sln project file, and for linux users there is a Makefile which can be used to compile this example program.

 

 Hi, Stefan,

drs_exam.cpp is working good to read-out one board.

Now I would like to read-out two boards at the same time using the same trigger( external or internal).

I'm trying to understand and modify the original code for control two board.

Meantime, it would be very appreciated if you give any tips for this.

Thanks,

Heejong

The evaluation boards are not really made for multi-board applications. What you have to do is to maintain an external trigger which synchronizes the boards. So you need:

- two boards connected to two USB ports

- an external flip-flop connected to the two trigger inputs of both boards

If a trigger is sent to the flip-flop, it sends a trigger to both evaluation boards. You poll on one of the boards to see if it has triggered (vis IsBusy()), then you read out both boards. Now you have to reset the external flip-flop somehow from the computer. If you have a CAMAC I/O board or some other means of sending a logical signal to it, that could do the job. From the software point, you get a "DRS" object upon initialization, which contains then two "DRSBoard" objects, over which you can iterate. Look at the "drscl" program from the distribution on how to do that.

Entry  Mon Apr 5 17:50:39 2010, Heejong Kim, version 1.2 evaluation board with firmware 13279? 
Hi, Stefan,

I found that my collaborator bought 2 older version of evaluation board before.
They are the version 1.2 in plastics case with firmware 13191.

Can I upgrade the firmware from 13191 to 13279?
I'm wondering if the older version of evaluation board is working with firmware 13279.

Thanks,
Heejong

    Reply  Wed Apr 14 16:34:28 2010, Stefan Ritt, version 1.2 evaluation board with firmware 13279? 

Heejong Kim wrote:
Hi, Stefan,

I found that my collaborator bought 2 older version of evaluation board before.
They are the version 1.2 in plastics case with firmware 13191.

Can I upgrade the firmware from 13191 to 13279?
I'm wondering if the older version of evaluation board is working with firmware 13279.

Thanks,
Heejong

I checked and there is no significant difference between the two revisions, so I would just leave it. 

Entry  Tue Mar 30 22:57:34 2010, Hao Huan, ROFS Configuration 

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.

 

    Reply  Thu Apr 15 13:48:40 2010, Stefan Ritt, ROFS Configuration 

Hao Huan wrote:

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.

Entry  Wed May 5 22:30:50 2010, Ignacio Diéguez Estremera, Random noise spec in datasheet 

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.

    Reply  Thu May 6 08:15:39 2010, Stefan Ritt, Random noise spec in datasheet 

Ignacio Diéguez Estremera wrote:

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.

Entry  Sun May 2 18:36:14 2010, Ignacio Diéguez Estremera, DRS4 chip model 

Hi all,

i'm an electronics engineering student at UCM (Madrid) working on my master's thesis within the CTA collaboration. I'm designing the readout electronics for the telescope's camera, and i'm focusing in using GAPDs instead of PMTs and using the domino chip for the sampling of the signal. I was wondering if there is a spice and/or RF model of the DRS4 chip available. It would be very useful to perform some simulations before deciding to use the chip as the sampling solution for our prototypes.

If the answer is negative, can you give me some advise for modelling the chip in spice? Have you done any simulations?

Thanks in advance,

Ignacio Diéguez Estremera.

    Reply  Mon May 3 11:09:12 2010, Stefan Ritt, DRS4 chip model 

Ignacio Diéguez Estremera wrote:

Hi all,

i'm an electronics engineering student at UCM (Madrid) working on my master's thesis within the CTA collaboration. I'm designing the readout electronics for the telescope's camera, and i'm focusing in using GAPDs instead of PMTs and using the domino chip for the sampling of the signal. I was wondering if there is a spice and/or RF model of the DRS4 chip available. It would be very useful to perform some simulations before deciding to use the chip as the sampling solution for our prototypes.

If the answer is negative, can you give me some advise for modelling the chip in spice? Have you done any simulations?

Thanks in advance,

Ignacio Diéguez Estremera.

Yes there is a transistor-level spice model, which I used to design the chip, but you won't be happy with it: Given the 500,000+ transistors on the chip, a 100 ns simulation takes a couple of weeks. We tried to make a simplified model just for the analog input using some measured S-parameters, but found that the RF behavior of the chip is almost impossible to describe to better than let's say 50%. In the end you have to fine-tune your analog front-end experimentally, to obtain optimal bandwidth. We are just working on a reference design with gives you 850 MHz bandwidth using an active input buffer.

       Reply  Mon May 3 17:06:02 2010, Ignacio Diéguez Estremera, DRS4 chip model 

Stefan Ritt wrote:

Ignacio Diéguez Estremera wrote:

Hi all,

i'm an electronics engineering student at UCM (Madrid) working on my master's thesis within the CTA collaboration. I'm designing the readout electronics for the telescope's camera, and i'm focusing in using GAPDs instead of PMTs and using the domino chip for the sampling of the signal. I was wondering if there is a spice and/or RF model of the DRS4 chip available. It would be very useful to perform some simulations before deciding to use the chip as the sampling solution for our prototypes.

If the answer is negative, can you give me some advise for modelling the chip in spice? Have you done any simulations?

Thanks in advance,

Ignacio Diéguez Estremera.

Yes there is a transistor-level spice model, which I used to design the chip, but you won't be happy with it: Given the 500,000+ transistors on the chip, a 100 ns simulation takes a couple of weeks. We tried to make a simplified model just for the analog input using some measured S-parameters, but found that the RF behavior of the chip is almost impossible to describe to better than let's say 50%. In the end you have to fine-tune your analog front-end experimentally, to obtain optimal bandwidth. We are just working on a reference design with gives you 850 MHz bandwidth using an active input buffer.

 Thanks for the information.

I would like to try the huge :-) model. Can you send it to my email address? Since the input signal are pulses of a few nanoseconds at FHWM, the simulation time may be reduced. I will post some feedback in the forum once i give it a try.

Kind regards.

          Reply  Mon May 3 17:10:29 2010, Stefan Ritt, DRS4 chip model 

Ignacio Diéguez Estremera wrote:

Stefan Ritt wrote:

Ignacio Diéguez Estremera wrote:

Hi all,

i'm an electronics engineering student at UCM (Madrid) working on my master's thesis within the CTA collaboration. I'm designing the readout electronics for the telescope's camera, and i'm focusing in using GAPDs instead of PMTs and using the domino chip for the sampling of the signal. I was wondering if there is a spice and/or RF model of the DRS4 chip available. It would be very useful to perform some simulations before deciding to use the chip as the sampling solution for our prototypes.

If the answer is negative, can you give me some advise for modelling the chip in spice? Have you done any simulations?

Thanks in advance,

Ignacio Diéguez Estremera.

Yes there is a transistor-level spice model, which I used to design the chip, but you won't be happy with it: Given the 500,000+ transistors on the chip, a 100 ns simulation takes a couple of weeks. We tried to make a simplified model just for the analog input using some measured S-parameters, but found that the RF behavior of the chip is almost impossible to describe to better than let's say 50%. In the end you have to fine-tune your analog front-end experimentally, to obtain optimal bandwidth. We are just working on a reference design with gives you 850 MHz bandwidth using an active input buffer.

 Thanks for the information.

I would like to try the huge :-) model. Can you send it to my email address? Since the input signal are pulses of a few nanoseconds at FHWM, the simulation time may be reduced. I will post some feedback in the forum once i give it a try.

Kind regards.

I just checked and realized that we are not allowed to give out the "huge" model since it contains parameters from the chip manufacturer's library which are confidentially. 

             Reply  Mon May 3 23:21:55 2010, Ignacio Diéguez Estremera, DRS4 chip model 

Stefan Ritt wrote:

Ignacio Diéguez Estremera wrote:

Stefan Ritt wrote:

Ignacio Diéguez Estremera wrote:

Hi all,

i'm an electronics engineering student at UCM (Madrid) working on my master's thesis within the CTA collaboration. I'm designing the readout electronics for the telescope's camera, and i'm focusing in using GAPDs instead of PMTs and using the domino chip for the sampling of the signal. I was wondering if there is a spice and/or RF model of the DRS4 chip available. It would be very useful to perform some simulations before deciding to use the chip as the sampling solution for our prototypes.

If the answer is negative, can you give me some advise for modelling the chip in spice? Have you done any simulations?

Thanks in advance,

Ignacio Diéguez Estremera.

Yes there is a transistor-level spice model, which I used to design the chip, but you won't be happy with it: Given the 500,000+ transistors on the chip, a 100 ns simulation takes a couple of weeks. We tried to make a simplified model just for the analog input using some measured S-parameters, but found that the RF behavior of the chip is almost impossible to describe to better than let's say 50%. In the end you have to fine-tune your analog front-end experimentally, to obtain optimal bandwidth. We are just working on a reference design with gives you 850 MHz bandwidth using an active input buffer.

 Thanks for the information.

I would like to try the huge :-) model. Can you send it to my email address? Since the input signal are pulses of a few nanoseconds at FHWM, the simulation time may be reduced. I will post some feedback in the forum once i give it a try.

Kind regards.

I just checked and realized that we are not allowed to give out the "huge" model since it contains parameters from the chip manufacturer's library which are confidentially. 

 Thank you for the effort anyway.

So i guess i won't be able to include drs4 in my simulations :-(. Any other suggestions? Maybe the S-params model you where working on? Anything is better than nothing :-)

                Reply  Tue May 4 11:26:21 2010, Stefan Ritt, DRS4 chip model DRS4_S-Parameter.pdf

Ignacio Diéguez Estremera wrote:

So i guess i won't be able to include drs4 in my simulations :-(. Any other suggestions? Maybe the S-params model you where working on? Anything is better than nothing :-)

Please find attached the S-parameters. 

                   Reply  Tue May 4 16:23:16 2010, Ignacio Diéguez Estremera, DRS4 chip model 

Stefan Ritt wrote:

Ignacio Diéguez Estremera wrote:

So i guess i won't be able to include drs4 in my simulations :-(. Any other suggestions? Maybe the S-params model you where working on? Anything is better than nothing :-)

Please find attached the S-parameters. 

 Thanks :-)

                   Reply  Wed May 12 11:47:39 2010, Jinhong Wang, DRS4 chip model 

Stefan Ritt wrote:

Ignacio Diéguez Estremera wrote:

So i guess i won't be able to include drs4 in my simulations :-(. Any other suggestions? Maybe the S-params model you where working on? Anything is better than nothing :-)

Please find attached the S-parameters. 

 Hi, we plan to do a time interpolating among the eight channels on a single chip to obtain a maximum 40 GSPS (or, maybe 30 GSPS ) sampling rate.  Hence RF behavior of the anlog input is very important for us.

Will you give us some advice on the modeling of  the anlog input circuit of the chip?  Perhaps just the Spice model of the analog input?

The attached S parameters I found  here is for fs =1 GSPS, what about fs=5GSPS?

thanks in advance,

                                                                               Jinhong Wang (wangjinh@mail.ustc.edu.cn  ;  alleyor.wang@gmail.com)

                      Reply  Wed May 12 16:26:12 2010, Stefan Ritt, DRS4 chip model 

Jinhong Wang wrote:

Stefan Ritt wrote:

Ignacio Diéguez Estremera wrote:

So i guess i won't be able to include drs4 in my simulations :-(. Any other suggestions? Maybe the S-params model you where working on? Anything is better than nothing :-)

Please find attached the S-parameters. 

 Hi, we plan to do a time interpolating among the eight channels on a single chip to obtain a maximum 40 GSPS (or, maybe 30 GSPS ) sampling rate.  Hence RF behavior of the anlog input is very important for us.

Will you give us some advice on the modeling of  the anlog input circuit of the chip?  Perhaps just the Spice model of the analog input?

The attached S parameters I found  here is for fs =1 GSPS, what about fs=5GSPS?

thanks in advance,

                                                                               Jinhong Wang (wangjinh@mail.ustc.edu.cn  ;  alleyor.wang@gmail.com)

To be honest, we never really succeeded to do any good simulation above let's say 500 MHz. We carefully tried to simulate the bond wire of the chip, the parasitic capacitances of the traces of the chip etc. but we always were off by a factor or two or so. Other groups reported the same problems. Some even did some 3D simulation model, without success. So our conclusion is that if you are interested in anything precise above 500 MHz, do a measurement.

So our current best design is with the THS4508. There is an AC coupled version going to 600 MHz, and a DC coupled version (uses more power) going to 800 MHz (-3dB). If you use passive inputs with a transformer for example, you can't go above 220 MHz. Next week I will publish both designs in this forum.

Entry  Wed May 26 19:18:09 2010, Hao Huan, High Frequency Input for DRS 

Hi Stefan,

    I read in the DRS datasheet that the bandwidth for the transparent mode OUT+ is only 200MHz which I think cannot be improved by any active input buffer; so if you want to operate the chip for really high frequency input, would it be better to feed on-board discriminators not from the output of DRS but from the input end?

    Thanks!

 

    Reply  Tue Jun 1 13:36:18 2010, Stefan Ritt, High Frequency Input for DRS 

Hao Huan wrote:

Hi Stefan,

    I read in the DRS datasheet that the bandwidth for the transparent mode OUT+ is only 200MHz which I think cannot be improved by any active input buffer; so if you want to operate the chip for really high frequency input, would it be better to feed on-board discriminators not from the output of DRS but from the input end?

    Thanks!

 

First, the 200 MHz is not correct. Table 1 clearly states ANALOG OUTPUTS - Bandwidth (-3dB): 50 MHz. This is also shown in plot 11 (revision 0.9). But that does not necessarily mean that you have to drive your discriminators from the input of the DRS4 chip. If you use this for triggering, a 1-2 ns timing jitter does not matter, since stopping the domino wave anyhow has a 3-4 cell jitter. If you send a very fast signal though a 50 MHz low pass filter, the timing anyhow doe not change, only the slope of your signal gets lower, so you are more sensitive to noise, which in turn causes the 1-2 ns timing jitter. But I personally would not worry about that too much. Putting any signal splitting components in the input path would reduce the input bandwidth, which would be much more of an issue.

Entry  Thu May 13 19:14:27 2010, Hao Huan, DVDD Problem of DRS 4 

Hi Stefan,

    on our board some DRS chips draw a lot of current through DVDD after power-up and heat up significantly--it is true that our board doesn't have weak pull-down resistors at DENABLE and DWRITE output pins of FPGA, so this problem might have been caused by that, but a reinitialization of the Domino circuit doesn't help either. We tried different capacitors at DVDD and it seemed the larger the capacitance, the better the result--with a capacitor larger than 10nF some of the DRS chips could work happily in the normal way while if the capacitor is only 4.7nF all of them got very hot. Would you please provide some suggestions why there should be such a problem?

    Thanks a lot!

    Reply  Fri May 14 08:40:14 2010, Stefan Ritt, DVDD Problem of DRS 4 

Hao Huan wrote:

Hi Stefan,

    on our board some DRS chips draw a lot of current through DVDD after power-up and heat up significantly--it is true that our board doesn't have weak pull-down resistors at DENABLE and DWRITE output pins of FPGA, so this problem might have been caused by that, but a reinitialization of the Domino circuit doesn't help either. We tried different capacitors at DVDD and it seemed the larger the capacitance, the better the result--with a capacitor larger than 10nF some of the DRS chips could work happily in the normal way while if the capacitor is only 4.7nF all of them got very hot. Would you please provide some suggestions why there should be such a problem?

    Thanks a lot!

I found that sometimes even a reinitialization fails if the pull-down resistors are missing. So instead playing with capacitors at DVDD, I would just solder two resistors on the board which should fix the problem completely.

       Reply  Tue May 18 01:47:59 2010, Hao Huan, DVDD Problem of DRS 4 

Stefan Ritt wrote:

Hao Huan wrote:

Hi Stefan,

    on our board some DRS chips draw a lot of current through DVDD after power-up and heat up significantly--it is true that our board doesn't have weak pull-down resistors at DENABLE and DWRITE output pins of FPGA, so this problem might have been caused by that, but a reinitialization of the Domino circuit doesn't help either. We tried different capacitors at DVDD and it seemed the larger the capacitance, the better the result--with a capacitor larger than 10nF some of the DRS chips could work happily in the normal way while if the capacitor is only 4.7nF all of them got very hot. Would you please provide some suggestions why there should be such a problem?

    Thanks a lot!

I found that sometimes even a reinitialization fails if the pull-down resistors are missing. So instead playing with capacitors at DVDD, I would just solder two resistors on the board which should fix the problem completely.

 Thanks! After adding pull-down resistors the voltages come back to normal.

However there is another weird problem that arises: a reset pulse seems unable to set the internal shift registers to default values. For example, after reset without addressing the Config Register the PLL will not try to lock with external reference clock. Even if I explicitly address the Config Register after reset and have the PLL locked, some channels of the chip will give null output during readout while other channels work normally. Could it be that some channels are not initiated properly with the Domino circuit?

          Reply  Tue May 18 08:23:07 2010, Stefan Ritt, DVDD Problem of DRS 4 

Hao Huan wrote:

Stefan Ritt wrote:

Hao Huan wrote:

Hi Stefan,

    on our board some DRS chips draw a lot of current through DVDD after power-up and heat up significantly--it is true that our board doesn't have weak pull-down resistors at DENABLE and DWRITE output pins of FPGA, so this problem might have been caused by that, but a reinitialization of the Domino circuit doesn't help either. We tried different capacitors at DVDD and it seemed the larger the capacitance, the better the result--with a capacitor larger than 10nF some of the DRS chips could work happily in the normal way while if the capacitor is only 4.7nF all of them got very hot. Would you please provide some suggestions why there should be such a problem?

    Thanks a lot!

I found that sometimes even a reinitialization fails if the pull-down resistors are missing. So instead playing with capacitors at DVDD, I would just solder two resistors on the board which should fix the problem completely.

 Thanks! After adding pull-down resistors the voltages come back to normal.

However there is another weird problem that arises: a reset pulse seems unable to set the internal shift registers to default values. For example, after reset without addressing the Config Register the PLL will not try to lock with external reference clock. Even if I explicitly address the Config Register after reset and have the PLL locked, some channels of the chip will give null output during readout while other channels work normally. Could it be that some channels are not initiated properly with the Domino circuit?

Something is wrong. I have 800 chips, and they all start up fine. Check with your scope the RESET, DSPEED, DENABLE and DTAP signals. When RESET is applied, DSPEED should go to 2.5 V. When DENABLE goes high, the domino wave is started and you should see DTAP toggle. DSPEED is then lowered by the PLL until DTAP matches your external reference clock. I usually keep DENABLE high all the time after initialization, so the domino wave just continues running.

Another problem could however be the chip readout. If some channel gives null output, it could be that your readout has a problem. Do you use RSRLOAD to initialize the readout sequence?

             Reply  Wed May 19 02:24:12 2010, Hao Huan, DVDD Problem of DRS 4 

Stefan Ritt wrote:

Hao Huan wrote:

Stefan Ritt wrote:

Hao Huan wrote:

Hi Stefan,

    on our board some DRS chips draw a lot of current through DVDD after power-up and heat up significantly--it is true that our board doesn't have weak pull-down resistors at DENABLE and DWRITE output pins of FPGA, so this problem might have been caused by that, but a reinitialization of the Domino circuit doesn't help either. We tried different capacitors at DVDD and it seemed the larger the capacitance, the better the result--with a capacitor larger than 10nF some of the DRS chips could work happily in the normal way while if the capacitor is only 4.7nF all of them got very hot. Would you please provide some suggestions why there should be such a problem?

    Thanks a lot!

I found that sometimes even a reinitialization fails if the pull-down resistors are missing. So instead playing with capacitors at DVDD, I would just solder two resistors on the board which should fix the problem completely.

 Thanks! After adding pull-down resistors the voltages come back to normal.

However there is another weird problem that arises: a reset pulse seems unable to set the internal shift registers to default values. For example, after reset without addressing the Config Register the PLL will not try to lock with external reference clock. Even if I explicitly address the Config Register after reset and have the PLL locked, some channels of the chip will give null output during readout while other channels work normally. Could it be that some channels are not initiated properly with the Domino circuit?

Something is wrong. I have 800 chips, and they all start up fine. Check with your scope the RESET, DSPEED, DENABLE and DTAP signals. When RESET is applied, DSPEED should go to 2.5 V. When DENABLE goes high, the domino wave is started and you should see DTAP toggle. DSPEED is then lowered by the PLL until DTAP matches your external reference clock. I usually keep DENABLE high all the time after initialization, so the domino wave just continues running.

Another problem could however be the chip readout. If some channel gives null output, it could be that your readout has a problem. Do you use RSRLOAD to initialize the readout sequence?

 Yes; I used RSRLOAD to trigger readout of all channels in parallel so the asymmetry between channels of the same chip is really a big puzzle. Also during reset DSPEED indeed goes to 2.5V, but after reset the PLL will not try to lock with the external reference clock and lower DSPEED. Instead the Domino circuit just oscillates at the highest frequency by itself.

A more confusing discovery is that the SRIN level before starting the Domino wave could affect the behavior of the PLL. I mean the level of SRIN when the chip is at A="1111" or "1010". Is SRIN supposed to influence the chip even in these standby or transparent modes?

                Reply  Wed May 19 09:16:02 2010, Stefan Ritt, DVDD Problem of DRS 4 

Hao Huan wrote:

Stefan Ritt wrote:

Hao Huan wrote:

Stefan Ritt wrote:

Hao Huan wrote:

Hi Stefan,

    on our board some DRS chips draw a lot of current through DVDD after power-up and heat up significantly--it is true that our board doesn't have weak pull-down resistors at DENABLE and DWRITE output pins of FPGA, so this problem might have been caused by that, but a reinitialization of the Domino circuit doesn't help either. We tried different capacitors at DVDD and it seemed the larger the capacitance, the better the result--with a capacitor larger than 10nF some of the DRS chips could work happily in the normal way while if the capacitor is only 4.7nF all of them got very hot. Would you please provide some suggestions why there should be such a problem?

    Thanks a lot!

I found that sometimes even a reinitialization fails if the pull-down resistors are missing. So instead playing with capacitors at DVDD, I would just solder two resistors on the board which should fix the problem completely.

 Thanks! After adding pull-down resistors the voltages come back to normal.

However there is another weird problem that arises: a reset pulse seems unable to set the internal shift registers to default values. For example, after reset without addressing the Config Register the PLL will not try to lock with external reference clock. Even if I explicitly address the Config Register after reset and have the PLL locked, some channels of the chip will give null output during readout while other channels work normally. Could it be that some channels are not initiated properly with the Domino circuit?

Something is wrong. I have 800 chips, and they all start up fine. Check with your scope the RESET, DSPEED, DENABLE and DTAP signals. When RESET is applied, DSPEED should go to 2.5 V. When DENABLE goes high, the domino wave is started and you should see DTAP toggle. DSPEED is then lowered by the PLL until DTAP matches your external reference clock. I usually keep DENABLE high all the time after initialization, so the domino wave just continues running.

Another problem could however be the chip readout. If some channel gives null output, it could be that your readout has a problem. Do you use RSRLOAD to initialize the readout sequence?

 Yes; I used RSRLOAD to trigger readout of all channels in parallel so the asymmetry between channels of the same chip is really a big puzzle. Also during reset DSPEED indeed goes to 2.5V, but after reset the PLL will not try to lock with the external reference clock and lower DSPEED. Instead the Domino circuit just oscillates at the highest frequency by itself.

A more confusing discovery is that the SRIN level before starting the Domino wave could affect the behavior of the PLL. I mean the level of SRIN when the chip is at A="1111" or "1010". Is SRIN supposed to influence the chip even in these standby or transparent modes?

Just some ideas:

  • Is DENABLE really kept high all the time?
  • Is DRESET only applied once during initialization, after that it should stay high
  • Does  REFCLK+/REFCLK- really toggle at the required sampling speed / 2048?
  • Is the REFCLK really a good differential signal? Note that it must be biased properly since the DRS4 inputs are high impedance
  • Is the Bit1 in the Config Register really at "1" to enable the PLL?

The only way the SRIN level could affect the PLL is if you address the Config Register (A="1100") and you clock in a few bits with SRCLK.

Have you thought about 'crazy' things such as:

  • Defining the DRS4 chip wronly in your CAD software so that the pins are different from what you think?
  • Some soldering problem of the DRS4 chips (we had this in the past) so that some pins are not connected at all and others have shorts

I guess you checked most of the things, so I'm just wildly guessing in order to stimulate some thoughts.

The ultimate check would be to get one of the evaluation boards (I sent a few to Jean-Francois Genat some time ago...) and compare the DRS4 signals pin by pin.

                   Reply  Fri Jun 18 11:31:20 2010, Jinhong Wang, DVDD Problem of DRS 4 

Stefan Ritt wrote:

Hao Huan wrote:

Stefan Ritt wrote:

Hao Huan wrote:

Stefan Ritt wrote:

Hao Huan wrote:

Hi Stefan,

    on our board some DRS chips draw a lot of current through DVDD after power-up and heat up significantly--it is true that our board doesn't have weak pull-down resistors at DENABLE and DWRITE output pins of FPGA, so this problem might have been caused by that, but a reinitialization of the Domino circuit doesn't help either. We tried different capacitors at DVDD and it seemed the larger the capacitance, the better the result--with a capacitor larger than 10nF some of the DRS chips could work happily in the normal way while if the capacitor is only 4.7nF all of them got very hot. Would you please provide some suggestions why there should be such a problem?

    Thanks a lot!

I found that sometimes even a reinitialization fails if the pull-down resistors are missing. So instead playing with capacitors at DVDD, I would just solder two resistors on the board which should fix the problem completely.

 Thanks! After adding pull-down resistors the voltages come back to normal.

However there is another weird problem that arises: a reset pulse seems unable to set the internal shift registers to default values. For example, after reset without addressing the Config Register the PLL will not try to lock with external reference clock. Even if I explicitly address the Config Register after reset and have the PLL locked, some channels of the chip will give null output during readout while other channels work normally. Could it be that some channels are not initiated properly with the Domino circuit?

Something is wrong. I have 800 chips, and they all start up fine. Check with your scope the RESET, DSPEED, DENABLE and DTAP signals. When RESET is applied, DSPEED should go to 2.5 V. When DENABLE goes high, the domino wave is started and you should see DTAP toggle. DSPEED is then lowered by the PLL until DTAP matches your external reference clock. I usually keep DENABLE high all the time after initialization, so the domino wave just continues running.

Another problem could however be the chip readout. If some channel gives null output, it could be that your readout has a problem. Do you use RSRLOAD to initialize the readout sequence?

 Yes; I used RSRLOAD to trigger readout of all channels in parallel so the asymmetry between channels of the same chip is really a big puzzle. Also during reset DSPEED indeed goes to 2.5V, but after reset the PLL will not try to lock with the external reference clock and lower DSPEED. Instead the Domino circuit just oscillates at the highest frequency by itself.

A more confusing discovery is that the SRIN level before starting the Domino wave could affect the behavior of the PLL. I mean the level of SRIN when the chip is at A="1111" or "1010". Is SRIN supposed to influence the chip even in these standby or transparent modes?

Just some ideas:

  • Is DENABLE really kept high all the time?
  • Is DRESET only applied once during initialization, after that it should stay high
  • Does  REFCLK+/REFCLK- really toggle at the required sampling speed / 2048?
  • Is the REFCLK really a good differential signal? Note that it must be biased properly since the DRS4 inputs are high impedance
  • Is the Bit1 in the Config Register really at "1" to enable the PLL?

The only way the SRIN level could affect the PLL is if you address the Config Register (A="1100") and you clock in a few bits with SRCLK.

Have you thought about 'crazy' things such as:

  • Defining the DRS4 chip wronly in your CAD software so that the pins are different from what you think?
  • Some soldering problem of the DRS4 chips (we had this in the past) so that some pins are not connected at all and others have shorts

I guess you checked most of the things, so I'm just wildly guessing in order to stimulate some thoughts.

The ultimate check would be to get one of the evaluation boards (I sent a few to Jean-Francois Genat some time ago...) and compare the DRS4 signals pin by pin.

 Hi Stefan

       I designed the evaluation board for our experiment. On our boards, I  encountered the similar problem when working on the PLL of DRS4. I compared the following two configuration process, which on with PLL locked, the other not,

   Process1: 

       step 1: Set DEnable and DWrite low, 

      Step2 : Reset DRS4 with a negative pulse of about 900 ns

      Step3: Set DEnable high,  thus do nothing but wait

       I found DRS4 PLL working and locked. 

  

  Process 2:

   Step 1: Set DEnable and DWrite low, 

  Step2 : Reset DRS4 with a negative pulse of about 900 ns 

  Step3: Set Config. Register( "11111111" .of course, this step was not necessary, just to see whether SPI was working properly from DTAP when set to "11111110")

  Step4: Set The read shift Register ( full read out mode)

  Step5: Set DEnable high, 

  Step6: Set DWrite high  , thus low it , and prepare to read the waveform.

  Well, I found in this case, the PLL was not locked, I am sure there was no problem with my SPI configuration process of DRS4. 

  toggle from DTAP could be viewed, but not stable. 

 Any Suggestions ?

  thanks.

                      Reply  Fri Jun 18 11:45:18 2010, Stefan Ritt, DVDD Problem of DRS 4 

Jinhong Wang wrote:

 

 Hi Stefan

       I designed the evaluation board for our experiment. On our boards, I  encountered the similar problem when working on the PLL of DRS4. I compared the following two configuration process, which on with PLL locked, the other not,

   Process1: 

       step 1: Set DEnable and DWrite low, 

      Step2 : Reset DRS4 with a negative pulse of about 900 ns

      Step3: Set DEnable high,  thus do nothing but wait

       I found DRS4 PLL working and locked. 

  

  Process 2:

   Step 1: Set DEnable and DWrite low, 

  Step2 : Reset DRS4 with a negative pulse of about 900 ns 

  Step3: Set Config. Register( "11111111" .of course, this step was not necessary, just to see whether SPI was working properly from DTAP when set to "11111110")

  Step4: Set The read shift Register ( full read out mode)

  Step5: Set DEnable high, 

  Step6: Set DWrite high  , thus low it , and prepare to read the waveform.

  Well, I found in this case, the PLL was not locked, I am sure there was no problem with my SPI configuration process of DRS4. 

  toggle from DTAP could be viewed, but not stable. 

 Any Suggestions ?

  thanks.

So the main difference, if I understand correctly, is the setting of the Config Register. Actually I never tried that, I always went with the default settings (all "1"). What happens if you write "00000000"? You know Bit1 controls the PLL, maybe there is a bug and the signal needs to be inverted. 

                         Reply  Sat Jun 19 10:09:18 2010, Jinhong Wang, DVDD Problem of DRS 4 

Stefan Ritt wrote:

Jinhong Wang wrote:

 

 Hi Stefan

       I designed the evaluation board for our experiment. On our boards, I  encountered the similar problem when working on the PLL of DRS4. I compared the following two configuration process, which on with PLL locked, the other not,

   Process1: 

       step 1: Set DEnable and DWrite low, 

      Step2 : Reset DRS4 with a negative pulse of about 900 ns

      Step3: Set DEnable high,  thus do nothing but wait

       I found DRS4 PLL working and locked. 

  

  Process 2:

   Step 1: Set DEnable and DWrite low, 

  Step2 : Reset DRS4 with a negative pulse of about 900 ns 

  Step3: Set Config. Register( "11111111" .of course, this step was not necessary, just to see whether SPI was working properly from DTAP when set to "11111110")

  Step4: Set The read shift Register ( full read out mode)

  Step5: Set DEnable high, 

  Step6: Set DWrite high  , thus low it , and prepare to read the waveform.

  Well, I found in this case, the PLL was not locked, I am sure there was no problem with my SPI configuration process of DRS4. 

  toggle from DTAP could be viewed, but not stable. 

 Any Suggestions ?

  thanks.

So the main difference, if I understand correctly, is the setting of the Config Register. Actually I never tried that, I always went with the default settings (all "1"). What happens if you write "00000000"? You know Bit1 controls the PLL, maybe there is a bug and the signal needs to be inverted. 

 Hi, Stefan,

       The problem was fixed by setting Reg_addr "1001" instead of "1111" when in idle state, I was confused. 

Entry  Tue Jun 22 10:50:19 2010, Jinhong Wang, Reset of DRS4 

 Hi Stefan, 

      I found DRS draw a lot of current when applied Reset after power on,  and the PLL does not work properly. I believe there was something that I misunderstood. So,  what will happen when Reset is applied more than once after power on? . Though the chip worked well without a Reset,   i want to try to find out what was wrong, for a better understanding of DRS. 

     best regards!

           Jinhong

    Reply  Tue Jun 22 11:02:30 2010, Stefan Ritt, Reset of DRS4 

Jinhong Wang wrote:

 Hi Stefan, 

      I found DRS draw a lot of current when applied Reset after power on,  and the PLL does not work properly. I believe there was something that I misunderstood. So,  what will happen when Reset is applied more than once after power on? . Though the chip worked well without a Reset,   i want to try to find out what was wrong, for a better understanding of DRS. 

     best regards!

           Jinhong

Have you made sure that DENABLE and DWRITE stays low during the reset? 

       Reply  Tue Jun 22 11:29:26 2010, Jinhong Wang, Reset of DRS4 

Stefan Ritt wrote:

Jinhong Wang wrote:

 Hi Stefan, 

      I found DRS draw a lot of current when applied Reset after power on,  and the PLL does not work properly. I believe there was something that I misunderstood. So,  what will happen when Reset is applied more than once after power on? . Though the chip worked well without a Reset,   i want to try to find out what was wrong, for a better understanding of DRS. 

     best regards!

           Jinhong

Have you made sure that DENABLE and DWRITE stays low during the reset? 

 Yes, they are stay low until Reset goes high. the process is as following

   Step1: Reset ='1', DEnable ='0', DWrite ='0', Reg_addr ="1111", Rsload='0', Srin ='0'

  Step2: Reset='0', the others do not change, the low of the pulse is longer than 10 ns.

  Step3: Reset='1', the others do not change, wait for some time

  Step4:  DEnable ='1' to start the domino.

          Reply  Tue Jun 22 11:35:18 2010, Stefan Ritt, Reset of DRS4 

Jinhong Wang wrote:

Stefan Ritt wrote:

Jinhong Wang wrote:

 Hi Stefan, 

      I found DRS draw a lot of current when applied Reset after power on,  and the PLL does not work properly. I believe there was something that I misunderstood. So,  what will happen when Reset is applied more than once after power on? . Though the chip worked well without a Reset,   i want to try to find out what was wrong, for a better understanding of DRS. 

     best regards!

           Jinhong

Have you made sure that DENABLE and DWRITE stays low during the reset? 

 Yes, they are stay low until Reset goes high. the process is as following

   Step1: Reset ='1', DEnable ='0', DWrite ='0', Reg_addr ="1111", Rsload='0', Srin ='0'

  Step2: Reset='0', the others do not change, the low of the pulse is longer than 10 ns.

  Step3: Reset='1', the others do not change, wait for some time

  Step4:  DEnable ='1' to start the domino.

Ok, then I have no idea. I never tried several reset pulses (actually this is not needed), so I have to reproduce the problem myself and investigate it. Actually in all my designs the reset input is just left open, since the internal initial reset is enough, so I have to modify my design first... 

             Reply  Tue Jun 22 11:37:42 2010, Jinhong Wang, Reset of DRS4 

Stefan Ritt wrote:

Jinhong Wang wrote:

Stefan Ritt wrote:

Jinhong Wang wrote:

 Hi Stefan, 

      I found DRS draw a lot of current when applied Reset after power on,  and the PLL does not work properly. I believe there was something that I misunderstood. So,  what will happen when Reset is applied more than once after power on? . Though the chip worked well without a Reset,   i want to try to find out what was wrong, for a better understanding of DRS. 

     best regards!

           Jinhong

Have you made sure that DENABLE and DWRITE stays low during the reset? 

 Yes, they are stay low until Reset goes high. the process is as following

   Step1: Reset ='1', DEnable ='0', DWrite ='0', Reg_addr ="1111", Rsload='0', Srin ='0'

  Step2: Reset='0', the others do not change, the low of the pulse is longer than 10 ns.

  Step3: Reset='1', the others do not change, wait for some time

  Step4:  DEnable ='1' to start the domino.

Ok, then I have no idea. I never tried several reset pulses (actually this is not needed), so I have to reproduce the problem myself and investigate it. Actually in all my designs the reset input is just left open, since the internal initial reset is enough, so I have to modify my design first... 

    Ok ,thank you. 

Entry  Mon Jul 12 16:07:37 2010, Stefan Ritt, Announcement evaluation board V3 eval3.png

Dear DRS4 users,

a new version of the evaluation board has been designed and is in production now. The main difference is that it uses active input amplifiers, which result in an analog bandwidth of 700 MHz (as compared with the 220 MHz of the previous board) at moderate power consumption, so the board can still be powered by the USB port. New orders will receive boards V3, the old V2 boards are not available any more.

It is mandatory to use the software revision 3.0.0 or later with the new board. This software has also many new features in the oscilloscope application, and together with the new firmware it reduces the noise of the board below 0.5 mV RMS. Although the software can be used with old V2 boards, some limitations might apply due to the old firmware of the boards. People having a Xilinx download cable can flash the firmware contained in the 3.0.0 revision to their V2 board to get all features of the new software.

The evaluation board manual V3 contains the new schematics of the analog inputs using the THS4508 differential amplifier, so people doing their own design can use this schematics as and example.

Best regards,

   Stefan Ritt

Entry  Wed Jul 21 10:46:32 2010, Jinhong Wang, ENOB of DRS 

 Hi, Stefan, I see in your ppt "Design and performance of 6 GSPS waveform digitizing chip DRS4" , you define DRS4 ENOB as 1Vpp/0.35mv(RMS) = 11.5bit, where, 1Vpp is the linearity input range, and 0.35mv is the rms voltage after offset correction. What I understand is that 0.35mV is obtained from DC offset Correction, hence 11.5 bit is for DC input, am i right?  If true, what about ENOB for AC input in the whole analog bandwidth?  thanks~

    Reply  Wed Jul 21 10:58:20 2010, Stefan Ritt, ENOB of DRS 

Jinhong Wang wrote:

 Hi, Stefan, I see in your ppt "Design and performance of 6 GSPS waveform digitizing chip DRS4" , you define DRS4 ENOB as 1Vpp/0.35mv(RMS) = 11.5bit, where, 1Vpp is the linearity input range, and 0.35mv is the rms voltage after offset correction. What I understand is that 0.35mV is obtained from DC offset Correction, hence 11.5 bit is for DC input, am i right?  If true, what about ENOB for AC input in the whole analog bandwidth?  thanks~

The expression ENOB for 1Vpp/0.35mV(RMS) is wrong, but I learned this later. Now I call it SNR. The ENOB is calculated in a more complicated way, see for example http://en.wikipedia.org/wiki/ENOB. If you measure the ENOB without timing correction, it's pretty poor (in the order of 7-8 bits). This is because without timing calibration, a sine input has huge side bands, and the ENOB involves the power of your signal over the power of the side bands. If you do a proper timing calibration, you spectrum gets "sharper", and hence the ENOB increases. But I have to admit that I never measured it carefully, since we are still optimizing the timing calibration. Once we have a perfect timing calibration, I will do it and update the data sheet. 

Entry  Tue May 18 09:24:02 2010, Stefan Ritt, Reference design for DRS4 active input buffer ac.pngac_bw.pngdc.pngdc_bw.pngDRS4_ft_V3.jpg

The design of high frequency differential input stages with the DRS4 is a challenge, since the chip draws quite some current at the input (up to 1 mA at 5 GSPS), which must be sourced by the input buffer. A simple transformer as used in the DRS4 Evaluation Board 2.0 limits the bandwidth to 220 MHz. In meantime two active input stages have been worked out and successfully been tested, both utilizing the THS4508 differential amplifier. The first design is AC-coupled and uses less power, the second design is DC-coupled and uses more power with the benefit of delivering a higher bandwidth.

Both designs use a clamping diode at the input as a protection against high voltage spikes at the input. We used a RCLAMP0502B diode from SEMTECH, but any fast voltage suppressor diode will do the job. 

The CMOFS input to the THS4508 set the common mode of the differential amplifier. In the AC version the level is set to mid-rail (2.5V), in the DC version it's set to 1.8V to match the input range of the DRS4.

The CAL+ and CAL- signals are used to bias the inputs to a well-defined DC level and can also be used to calibrate the chip. For bipolar inputs, they are both set to 0.8V. A positive 0.5V input pulse then drives DRS_IN+ to (0.8+0.25)V = 1.05V and DRS_IN- to (0.8-0.25)V = 0.55V. A negative 0.5V pulse then drives then DRS_IN+ to 0.55V and DRS_IN- to 1.05V. With ROFS=1.6V, the full dynamic range of the DRS4 is then used. Note that the THS4508 has a gain of 2, and the input has a -6dB voltage divider to compensate for that. To use other input ranges, such as -1V...0V, the CAL+ and CAL- signals can be adjusted accordingly. Note that the inputs of the DRS4 must always be between 0.1V and 1.5V.

 

AC-coupled version

ac.png
                                                                                                                                                                                                                                     (click to enlarge)

Power supply: +5 V 40 mA

Bandwidth (-3dB): 600 MHz

CMOFS: 2.5 V

Transfer function:

ac_bw.png
                                                                                                                                                            (click to enlarge)

The transfer function was measured by applying a fixed amplitude sine wave to the input, and measuring the peak-to-peak value of the read out waveform with the DRSOsc application.

DC-coupled Version

The DC-coupled version has a slightly higher power consumption since there is a constant current flowing through the output into the DRS4 chip. On the other hand, the bandwidth is a bit higher and the peaking around 400 MHz is a bit smaller. The input is still AC-coupled, so both positive and negative pulses can be accepted. 

dc.png
                                                                                                                                                                                                                             (click to enlarge)

Power supply: +5 V 115 mA

Bandwidth (-3dB): 800 MHz

CMOFS: 1.8 V

Transfer function:

dc_bw.png
                                                                                                                                                              (click to enlarge)

Achievable performance

With the active input stage, much faster rise- and fall times can be achieved. Following picture shows a signal from a external clock having a fall time of about 300 ps being recorded with the AC-coupled version of the active input stage. The fall time of the recorded signal is about 800 ps, which is about the minimum which can be achieved with the AC-coupled version. The DC-coupled version achieves about 700ps.

DRS4_ft_V3.jpg

    Reply  Tue Oct 12 03:53:37 2010, Jinhong Wang, Reference design for DRS4 active input buffer 

Stefan Ritt wrote:

The design of high frequency differential input stages with the DRS4 is a challenge, since the chip draws quite some current at the input (up to 1 mA at 5 GSPS), which must be sourced by the input buffer. A simple transformer as used in the DRS4 Evaluation Board 2.0 limits the bandwidth to 220 MHz. In meantime two active input stages have been worked out and successfully been tested, both utilizing the THS4508 differential amplifier. The first design is AC-coupled and uses less power, the second design is DC-coupled and uses more power with the benefit of delivering a higher bandwidth.

Both designs use a clamping diode at the input as a protection against high voltage spikes at the input. We used a RCLAMP0502B diode from SEMTECH, but any fast voltage suppressor diode will do the job. 

The CMOFS input to the THS4508 set the common mode of the differential amplifier. In the AC version the level is set to mid-rail (2.5V), in the DC version it's set to 1.8V to match the input range of the DRS4.

The CAL+ and CAL- signals are used to bias the inputs to a well-defined DC level and can also be used to calibrate the chip. For bipolar inputs, they are both set to 0.8V. A positive 0.5V input pulse then drives DRS_IN+ to (0.8+0.25)V = 1.05V and DRS_IN- to (0.8-0.25)V = 0.55V. A negative 0.5V pulse then drives then DRS_IN+ to 0.55V and DRS_IN- to 1.05V. With ROFS=1.6V, the full dynamic range of the DRS4 is then used. Note that the THS4508 has a gain of 2, and the input has a -6dB voltage divider to compensate for that. To use other input ranges, such as -1V...0V, the CAL+ and CAL- signals can be adjusted accordingly. Note that the inputs of the DRS4 must always be between 0.1V and 1.5V.

 

AC-coupled version

ac.png
                                                                                                                                                                                                                                     (click to enlarge)

Power supply: +5 V 40 mA

Bandwidth (-3dB): 600 MHz

CMOFS: 2.5 V

Transfer function:

ac_bw.png
                                                                                                                                                            (click to enlarge)

The transfer function was measured by applying a fixed amplitude sine wave to the input, and measuring the peak-to-peak value of the read out waveform with the DRSOsc application.

DC-coupled Version

The DC-coupled version has a slightly higher power consumption since there is a constant current flowing through the output into the DRS4 chip. On the other hand, the bandwidth is a bit higher and the peaking around 400 MHz is a bit smaller. The input is still AC-coupled, so both positive and negative pulses can be accepted. 

dc.png
                                                                                                                                                                                                                             (click to enlarge)

Power supply: +5 V 115 mA

Bandwidth (-3dB): 800 MHz

CMOFS: 1.8 V

Transfer function:

dc_bw.png
                                                                                                                                                              (click to enlarge)

Achievable performance

With the active input stage, much faster rise- and fall times can be achieved. Following picture shows a signal from a external clock having a fall time of about 300 ps being recorded with the AC-coupled version of the active input stage. The fall time of the recorded signal is about 800 ps, which is about the minimum which can be achieved with the AC-coupled version. The DC-coupled version achieves about 700ps.

DRS4_ft_V3.jpg

 Hi, stefan,

     In the DC coupled version of the analog drivers for DRS4 input in Eval. Board V3, you mentioned that CMOFS of THS4508 was set to 1.8V to match the input range of DRS4, however, will this clash with the requirements of  DRS4 input voltage between 0.1 V ~1.5V ? The output of THS4508 can easily rise beyond 1.5V for CMOFS=1.8V. I also noticed the resister paris R13/R15, R14/R16 was added among the output of THS4508 and the inputs of DRS4, were these resister pairs were used to attenuate the level of THS4508 output signal (a half ? ) to match the input requirements of DRS4? Maybe I have some misunderstanding about it.

       Reply  Tue Nov 16 16:38:06 2010, Stefan Ritt, Reference design for DRS4 active input buffer 

Jinhong Wang wrote:

 

 Hi, stefan,

 

     In the DC coupled version of the analog drivers for DRS4 input in Eval. Board V3, you mentioned that CMOFS of THS4508 was set to 1.8V to match the input range of DRS4, however, will this clash with the requirements of  DRS4 input voltage between 0.1 V ~1.5V ? The output of THS4508 can easily rise beyond 1.5V for CMOFS=1.8V. I also noticed the resister paris R13/R15, R14/R16 was added among the output of THS4508 and the inputs of DRS4, were these resister pairs were used to attenuate the level of THS4508 output signal (a half ? ) to match the input requirements of DRS4? Maybe I have some misunderstanding about it.

 

No you are right about that. The THS4508 has a gain of +2, and by using the resistor pairs we do

1) Reduce the gain back to unity

2) Reduce the input DC level from 1.8V to 0.9V to match the input range

3) Terminate the signals at the input of the DRS chip to minimize reflections

I know this is not so obvious from the schematic, so thanks for asking.

- Stefan 

Entry  Sat Feb 19 17:25:29 2011, S S Upadhya, how to synchronize Sampling frequency of two evaluation boards 

 Dear sir,

We have two evaluation boards of DRS4. We would like to use 8 inputs to be recorded on a trigger and we would like to find the relative time difference of inputs. So is it possible to synchronize the sampling frequency of the two evaluation boards. 

with best regards

S S Upadhya

    Reply  Sat Feb 19 22:46:35 2011, Stefan Ritt, how to synchronize Sampling frequency of two evaluation boards 

S S Upadhya wrote:

 Dear sir,

We have two evaluation boards of DRS4. We would like to use 8 inputs to be recorded on a trigger and we would like to find the relative time difference of inputs. So is it possible to synchronize the sampling frequency of the two evaluation boards. 

with best regards

S S Upadhya

No, not in this version. We plan a future version of the evaluation board with clock synchronization, but that board will not be ready before 2-3 months. Anyhow the board is more meant as an evaluation board, to test the chip and develop own electronics, and not to build a complete DAQ system. Note that CAEN distributes now a VME board containing the four DRS4 chips and 32 channels on a board. 

       Reply  Mon Feb 21 08:10:31 2011, Stefan Ritt, how to synchronize Sampling frequency of two evaluation boards 

Stefan Ritt wrote:

S S Upadhya wrote:

 Dear sir,

We have two evaluation boards of DRS4. We would like to use 8 inputs to be recorded on a trigger and we would like to find the relative time difference of inputs. So is it possible to synchronize the sampling frequency of the two evaluation boards. 

with best regards

S S Upadhya

No, not in this version. We plan a future version of the evaluation board with clock synchronization, but that board will not be ready before 2-3 months. Anyhow the board is more meant as an evaluation board, to test the chip and develop own electronics, and not to build a complete DAQ system. Note that CAEN distributes now a VME board containing the four DRS4 chips and 32 channels on a board. 

Well, one thing you can do is to generate an external trigger and send it to the external trigger input of both cards. Then you can determine the time in respect to the trigger point in both boards. But since the trigger cell jitters by 2-3 cells in each chip, the accuracy is limited to about 1-2 ns when running at 2 GS/s. 

          Reply  Mon Feb 21 12:42:33 2011, S S Upadhya, how to synchronize Sampling frequency of two evaluation boards 

Stefan Ritt wrote:

Stefan Ritt wrote:

S S Upadhya wrote:

 Dear sir,

We have two evaluation boards of DRS4. We would like to use 8 inputs to be recorded on a trigger and we would like to find the relative time difference of inputs. So is it possible to synchronize the sampling frequency of the two evaluation boards. 

with best regards

S S Upadhya

No, not in this version. We plan a future version of the evaluation board with clock synchronization, but that board will not be ready before 2-3 months. Anyhow the board is more meant as an evaluation board, to test the chip and develop own electronics, and not to build a complete DAQ system. Note that CAEN distributes now a VME board containing the four DRS4 chips and 32 channels on a board. 

Well, one thing you can do is to generate an external trigger and send it to the external trigger input of both cards. Then you can determine the time in respect to the trigger point in both boards. But since the trigger cell jitters by 2-3 cells in each chip, the accuracy is limited to about 1-2 ns when running at 2 GS/s. 

 

 

 Dear Stefan,

Thanks for the second suggestion. I wanted to do feasibility study of  DRS4 application to our requirement in the experiment 

Thank you again sir,

Upadhya

Entry  Fri Feb 25 10:13:51 2011, Stefan Ritt, Announcement digital pulse processing workshop 

Dear colleague,

if you live not so far from Zurich, you might be interested in this workshop:

http://www.xtronix.ch/hep/psi_workshop.htm

This is a combined PSI-CAEN presentation of digitizer hardware including the new V1742 board based on the DRS4 chip. The workshop will also show how digital pulse processing can be used to effectively extract time and energy from detector signals, and thus replace more and more traditional analog electronics. Please register at the above site if you are interested.

Best regards,

    Stefan Ritt

Entry  Wed Jun 1 09:57:43 2011, Martin Petriska, Removing spikes 

I have DSR4 eval board. Found that there are spikes in channels. Procedure Osc::RemoveSpikes to remove them looks litlle dificult. There is simple way, if you doesnt need to measure all 4 channels.Spikes are in all channels, and it looks like they are same in time and value between channels. To remove them, if you are not using one channel, substract that unused channel with spikes from used channel and your data will be without spikes. If you need all 4 inputs, then may be channel 9 could be substracted.

    Reply  Thu Jun 2 21:01:29 2011, Stefan Ritt, Removing spikes 

Martin Petriska wrote:

I have DSR4 eval board. Found that there are spikes in channels. Procedure Osc::RemoveSpikes to remove them looks litlle dificult. There is simple way, if you doesnt need to measure all 4 channels.Spikes are in all channels, and it looks like they are same in time and value between channels. To remove them, if you are not using one channel, substract that unused channel with spikes from used channel and your data will be without spikes. If you need all 4 inputs, then may be channel 9 could be substracted.

Indeed that's what I had before. If you don't need the 9th channels, you can use it to identify the spikes. But we have applications where we need all 9 channels. That's why I made Osc::RemoveSpikes a bit more complicated, so it will still work when all 9 channels are used. This new version is release 3.1.0. If you just blindly subtract the 9th channel, your noise could increase by a sqrt(2). 

Entry  Mon Jul 19 12:07:04 2010, Jinhong Wang, Fixed Patter Timing Jitter 

 Hi Stefan, can you give some suggestions on determination of fixed pattern timing jitter of DRS4?  Thanks~

    Reply  Mon Jul 19 12:47:17 2010, Stefan Ritt, Fixed Patter Timing Jitter Capture.png

Jinhong Wang wrote:

 Hi Stefan, can you give some suggestions on determination of fixed pattern timing jitter of DRS4?  Thanks~

I will prepare some more detailed description of how to do this in the near future, but we are still learning ourselves constantly how to do that better. 


So for the moment I only can recommend you to read the function DRSBoard::CalibrateTiming() and AnalyzeWF(). What you basically do is to define an array of "effective" bin widths t[i]. You start with the nominal bin width (let's say 500ps at 2 GSPS). Now you measure a periodic signal, and look for the zero crossings. If you have a 100 MHz clock, the time between two positive transitions (low-to-high) is 10.000ns. Now you measure the width as seen by the DRS chip, assuming the effective bin widths. The exact zero crossing you interpolate between two samples to improve the accuracy. Now you measure something different, let's say 10.1ns. So you know the ~20 bins between the zero crossings are "too wide", but you don't know which one of them is too wide. So you distribute the "too wide" equally between all bins, that is you decrease the effective width of these bins from 500ps to 500-0.1ns/20=499.995 ps. Then you do this iteratively, that is for all cycles in the waveform, and for many (1000's) of recorded waveforms. It is important that the phase of you measured clock is random, so that all bins are covered equally. Then you realize that the solution oscillates, which you can reduce by using a damping factor (called "damping" in my C code). So you do not correct to 499.995ps, but maybe to 499.999ps. If you iterate often enough, the solution kind of stabilizes.

The attached picture shows the result of such a calibration. Green is the effective bin width which in the end only slightly deviates from 500ps. But the "integral temporal nonlinearity" shows a typical shape for the DRS chip. It's defined as

          n
 Ti[n] = Sum (t[i]-500ps)
         i=0

where t[i] is the effective bin width. So Ti[0] is zero by definition, but the deviation around bin 450 can go up to 1ns at 2 GSPS.

Now you can test you calibration, by measuring again the period of your clock. If you do everything correctly and have a low jitter external clock and no noise on your DRS4 power supply voltages, you should see a residual jitter of about 40ps.

Hope this explanation helps a bit. Let me know if I was not clear enough at some points. 

- Stefan

       Reply  Mon Jul 4 05:06:00 2011, Jinhong Wang, Fixed Patter Timing Jitter hist_stoppos.jpg

Stefan Ritt wrote:

Jinhong Wang wrote:

 Hi Stefan, can you give some suggestions on determination of fixed pattern timing jitter of DRS4?  Thanks~

I will prepare some more detailed description of how to do this in the near future, but we are still learning ourselves constantly how to do that better. 


So for the moment I only can recommend you to read the function DRSBoard::CalibrateTiming() and AnalyzeWF(). What you basically do is to define an array of "effective" bin widths t[i]. You start with the nominal bin width (let's say 500ps at 2 GSPS). Now you measure a periodic signal, and look for the zero crossings. If you have a 100 MHz clock, the time between two positive transitions (low-to-high) is 10.000ns. Now you measure the width as seen by the DRS chip, assuming the effective bin widths. The exact zero crossing you interpolate between two samples to improve the accuracy. Now you measure something different, let's say 10.1ns. So you know the ~20 bins between the zero crossings are "too wide", but you don't know which one of them is too wide. So you distribute the "too wide" equally between all bins, that is you decrease the effective width of these bins from 500ps to 500-0.1ns/20=499.995 ps. Then you do this iteratively, that is for all cycles in the waveform, and for many (1000's) of recorded waveforms. It is important that the phase of you measured clock is random, so that all bins are covered equally. Then you realize that the solution oscillates, which you can reduce by using a damping factor (called "damping" in my C code). So you do not correct to 499.995ps, but maybe to 499.999ps. If you iterate often enough, the solution kind of stabilizes.

The attached picture shows the result of such a calibration. Green is the effective bin width which in the end only slightly deviates from 500ps. But the "integral temporal nonlinearity" shows a typical shape for the DRS chip. It's defined as

          n
 Ti[n] = Sum (t[i]-500ps)
         i=0

where t[i] is the effective bin width. So Ti[0] is zero by definition, but the deviation around bin 450 can go up to 1ns at 2 GSPS.

Now you can test you calibration, by measuring again the period of your clock. If you do everything correctly and have a low jitter external clock and no noise on your DRS4 power supply voltages, you should see a residual jitter of about 40ps.

Hope this explanation helps a bit. Let me know if I was not clear enough at some points. 

- Stefan

 Hi, Stefan,

    I noticed other groups of SCA reported the technique to histogram the zero crossings of a sine wave, and use the bin occupancy to derive the effective aperture width.  Recently , I tried this technique to DRS4. In my test, the frequency of the sine wave was selected uncorrelated to the domino frequency.The results were discouraging. Large variations of the domino tap delay was observed.   Besides, I also tried to induce an external trigger, which is uncorrelated to the domino frequency, and histogram the stop positions. Unfortunately, large variations were obtained again. I knew there must be something wrong. Do you have any suggestions?

   The attachment is the histogram of the stop positions (the vertical axis is the bin count, the horizontal axis is the bin number). First, I calculate the ration of each bin count to the total counts, supposed the total count is 10000, count of bin 37 is 12, so the corresponding ratio is 12/10000=0.0012. The bin delay is derived by multiplying its ratio to the whole domino period (1024*1/FSamp, eg., for 5 GSP/s, this period is 200ps *1024). (The bin delay i observed was with an variation of about 30 ps).  If the external trigger is uncorrelated to the domino frequency, so, the stop positions are supposed to distribute equally to all bins? If this is true, can i calculate the bin delay via the histogram ?

   thank you~

                 Wang Jinhong

          Reply  Tue Jul 5 10:09:43 2011, Stefan Ritt, Fixed Patter Timing Jitter nonlinearity.png

Jinhong Wang wrote:

Stefan Ritt wrote:

Jinhong Wang wrote:

 Hi Stefan, can you give some suggestions on determination of fixed pattern timing jitter of DRS4?  Thanks~

I will prepare some more detailed description of how to do this in the near future, but we are still learning ourselves constantly how to do that better. 


So for the moment I only can recommend you to read the function DRSBoard::CalibrateTiming() and AnalyzeWF(). What you basically do is to define an array of "effective" bin widths t[i]. You start with the nominal bin width (let's say 500ps at 2 GSPS). Now you measure a periodic signal, and look for the zero crossings. If you have a 100 MHz clock, the time between two positive transitions (low-to-high) is 10.000ns. Now you measure the width as seen by the DRS chip, assuming the effective bin widths. The exact zero crossing you interpolate between two samples to improve the accuracy. Now you measure something different, let's say 10.1ns. So you know the ~20 bins between the zero crossings are "too wide", but you don't know which one of them is too wide. So you distribute the "too wide" equally between all bins, that is you decrease the effective width of these bins from 500ps to 500-0.1ns/20=499.995 ps. Then you do this iteratively, that is for all cycles in the waveform, and for many (1000's) of recorded waveforms. It is important that the phase of you measured clock is random, so that all bins are covered equally. Then you realize that the solution oscillates, which you can reduce by using a damping factor (called "damping" in my C code). So you do not correct to 499.995ps, but maybe to 499.999ps. If you iterate often enough, the solution kind of stabilizes.

The attached picture shows the result of such a calibration. Green is the effective bin width which in the end only slightly deviates from 500ps. But the "integral temporal nonlinearity" shows a typical shape for the DRS chip. It's defined as

          n
 Ti[n] = Sum (t[i]-500ps)
         i=0

where t[i] is the effective bin width. So Ti[0] is zero by definition, but the deviation around bin 450 can go up to 1ns at 2 GSPS.

Now you can test you calibration, by measuring again the period of your clock. If you do everything correctly and have a low jitter external clock and no noise on your DRS4 power supply voltages, you should see a residual jitter of about 40ps.

Hope this explanation helps a bit. Let me know if I was not clear enough at some points. 

- Stefan

 Hi, Stefan,

    I noticed other groups of SCA reported the technique to histogram the zero crossings of a sine wave, and use the bin occupancy to derive the effective aperture width.  Recently , I tried this technique to DRS4. In my test, the frequency of the sine wave was selected uncorrelated to the domino frequency.The results were discouraging. Large variations of the domino tap delay was observed.   Besides, I also tried to induce an external trigger, which is uncorrelated to the domino frequency, and histogram the stop positions. Unfortunately, large variations were obtained again. I knew there must be something wrong. Do you have any suggestions?

   The attachment is the histogram of the stop positions (the vertical axis is the bin count, the horizontal axis is the bin number). First, I calculate the ration of each bin count to the total counts, supposed the total count is 10000, count of bin 37 is 12, so the corresponding ratio is 12/10000=0.0012. The bin delay is derived by multiplying its ratio to the whole domino period (1024*1/FSamp, eg., for 5 GSP/s, this period is 200ps *1024). (The bin delay i observed was with an variation of about 30 ps).  If the external trigger is uncorrelated to the domino frequency, so, the stop positions are supposed to distribute equally to all bins? If this is true, can i calculate the bin delay via the histogram ?

   thank you~

                 Wang Jinhong

One obvious problem in your method is your statistics. If you have n hits in a bin of the histogram, the error of n is sqrt(n). So if you measure 100 hits, this is more like 100+-10 hits. If you want a better precision, you need much higher statistics. I myself never used this method, but I attach a typical nonlinearity curve running at 2 GSPS, sot hat you know what you should expect. I do some smoothing between neighbor bins so that they do not scatter too much. As you can see, the integral nonlinearity goes almost up to +-2 ns. This value is smaller at higher sampling speeds.

 - Stefan 

             Reply  Tue Jul 12 09:49:08 2011, Jinhong Wang, Fixed Patter Timing Jitter 131MHz.jpg

Stefan Ritt wrote:

Jinhong Wang wrote:

Stefan Ritt wrote:

Jinhong Wang wrote:

 Hi Stefan, can you give some suggestions on determination of fixed pattern timing jitter of DRS4?  Thanks~

I will prepare some more detailed description of how to do this in the near future, but we are still learning ourselves constantly how to do that better. 


So for the moment I only can recommend you to read the function DRSBoard::CalibrateTiming() and AnalyzeWF(). What you basically do is to define an array of "effective" bin widths t[i]. You start with the nominal bin width (let's say 500ps at 2 GSPS). Now you measure a periodic signal, and look for the zero crossings. If you have a 100 MHz clock, the time between two positive transitions (low-to-high) is 10.000ns. Now you measure the width as seen by the DRS chip, assuming the effective bin widths. The exact zero crossing you interpolate between two samples to improve the accuracy. Now you measure something different, let's say 10.1ns. So you know the ~20 bins between the zero crossings are "too wide", but you don't know which one of them is too wide. So you distribute the "too wide" equally between all bins, that is you decrease the effective width of these bins from 500ps to 500-0.1ns/20=499.995 ps. Then you do this iteratively, that is for all cycles in the waveform, and for many (1000's) of recorded waveforms. It is important that the phase of you measured clock is random, so that all bins are covered equally. Then you realize that the solution oscillates, which you can reduce by using a damping factor (called "damping" in my C code). So you do not correct to 499.995ps, but maybe to 499.999ps. If you iterate often enough, the solution kind of stabilizes.

The attached picture shows the result of such a calibration. Green is the effective bin width which in the end only slightly deviates from 500ps. But the "integral temporal nonlinearity" shows a typical shape for the DRS chip. It's defined as

          n
 Ti[n] = Sum (t[i]-500ps)
         i=0

where t[i] is the effective bin width. So Ti[0] is zero by definition, but the deviation around bin 450 can go up to 1ns at 2 GSPS.

Now you can test you calibration, by measuring again the period of your clock. If you do everything correctly and have a low jitter external clock and no noise on your DRS4 power supply voltages, you should see a residual jitter of about 40ps.

Hope this explanation helps a bit. Let me know if I was not clear enough at some points. 

- Stefan

 Hi, Stefan,

    I noticed other groups of SCA reported the technique to histogram the zero crossings of a sine wave, and use the bin occupancy to derive the effective aperture width.  Recently , I tried this technique to DRS4. In my test, the frequency of the sine wave was selected uncorrelated to the domino frequency.The results were discouraging. Large variations of the domino tap delay was observed.   Besides, I also tried to induce an external trigger, which is uncorrelated to the domino frequency, and histogram the stop positions. Unfortunately, large variations were obtained again. I knew there must be something wrong. Do you have any suggestions?

   The attachment is the histogram of the stop positions (the vertical axis is the bin count, the horizontal axis is the bin number). First, I calculate the ration of each bin count to the total counts, supposed the total count is 10000, count of bin 37 is 12, so the corresponding ratio is 12/10000=0.0012. The bin delay is derived by multiplying its ratio to the whole domino period (1024*1/FSamp, eg., for 5 GSP/s, this period is 200ps *1024). (The bin delay i observed was with an variation of about 30 ps).  If the external trigger is uncorrelated to the domino frequency, so, the stop positions are supposed to distribute equally to all bins? If this is true, can i calculate the bin delay via the histogram ?

   thank you~

                 Wang Jinhong

One obvious problem in your method is your statistics. If you have n hits in a bin of the histogram, the error of n is sqrt(n). So if you measure 100 hits, this is more like 100+-10 hits. If you want a better precision, you need much higher statistics. I myself never used this method, but I attach a typical nonlinearity curve running at 2 GSPS, sot hat you know what you should expect. I do some smoothing between neighbor bins so that they do not scatter too much. As you can see, the integral nonlinearity goes almost up to +-2 ns. This value is smaller at higher sampling speeds.

 - Stefan 

 Thank you, Stefan. It is really kind of you to offer suggestions or comments on our concern. 

Recently, we input a sine wave to our DRS board. DRS works at about 5 GS/s. The frequency varies from 131 MHz to 231MHz. The attached picture shows the reconstructed points of sine wave (vertical is the amplitude, horizontal axis is the point numbers). We noticed that the variation of the length of the zero crossing segments is very large. The max. length is perhaps two times the length of the min. I marked in blue color in the picture.  It means the corresponding sampling interval of the max. is two times of that of the min.  If this is true, DNL of the DRS sampling interval would be very large. We know, for uniform sampling, the length of the zero crossing segments are assumed to be uniform.  Do you have any comments? Thank you~

                Reply  Wed Jul 13 04:26:52 2011, Stefan Ritt, Fixed Patter Timing Jitter 

Jinhong Wang wrote:

Stefan Ritt wrote:

Jinhong Wang wrote:

Stefan Ritt wrote:

Jinhong Wang wrote:

 Hi Stefan, can you give some suggestions on determination of fixed pattern timing jitter of DRS4?  Thanks~

I will prepare some more detailed description of how to do this in the near future, but we are still learning ourselves constantly how to do that better. 


So for the moment I only can recommend you to read the function DRSBoard::CalibrateTiming() and AnalyzeWF(). What you basically do is to define an array of "effective" bin widths t[i]. You start with the nominal bin width (let's say 500ps at 2 GSPS). Now you measure a periodic signal, and look for the zero crossings. If you have a 100 MHz clock, the time between two positive transitions (low-to-high) is 10.000ns. Now you measure the width as seen by the DRS chip, assuming the effective bin widths. The exact zero crossing you interpolate between two samples to improve the accuracy. Now you measure something different, let's say 10.1ns. So you know the ~20 bins between the zero crossings are "too wide", but you don't know which one of them is too wide. So you distribute the "too wide" equally between all bins, that is you decrease the effective width of these bins from 500ps to 500-0.1ns/20=499.995 ps. Then you do this iteratively, that is for all cycles in the waveform, and for many (1000's) of recorded waveforms. It is important that the phase of you measured clock is random, so that all bins are covered equally. Then you realize that the solution oscillates, which you can reduce by using a damping factor (called "damping" in my C code). So you do not correct to 499.995ps, but maybe to 499.999ps. If you iterate often enough, the solution kind of stabilizes.

The attached picture shows the result of such a calibration. Green is the effective bin width which in the end only slightly deviates from 500ps. But the "integral temporal nonlinearity" shows a typical shape for the DRS chip. It's defined as

          n
 Ti[n] = Sum (t[i]-500ps)
         i=0

where t[i] is the effective bin width. So Ti[0] is zero by definition, but the deviation around bin 450 can go up to 1ns at 2 GSPS.

Now you can test you calibration, by measuring again the period of your clock. If you do everything correctly and have a low jitter external clock and no noise on your DRS4 power supply voltages, you should see a residual jitter of about 40ps.

Hope this explanation helps a bit. Let me know if I was not clear enough at some points. 

- Stefan

 Hi, Stefan,

    I noticed other groups of SCA reported the technique to histogram the zero crossings of a sine wave, and use the bin occupancy to derive the effective aperture width.  Recently , I tried this technique to DRS4. In my test, the frequency of the sine wave was selected uncorrelated to the domino frequency.The results were discouraging. Large variations of the domino tap delay was observed.   Besides, I also tried to induce an external trigger, which is uncorrelated to the domino frequency, and histogram the stop positions. Unfortunately, large variations were obtained again. I knew there must be something wrong. Do you have any suggestions?

   The attachment is the histogram of the stop positions (the vertical axis is the bin count, the horizontal axis is the bin number). First, I calculate the ration of each bin count to the total counts, supposed the total count is 10000, count of bin 37 is 12, so the corresponding ratio is 12/10000=0.0012. The bin delay is derived by multiplying its ratio to the whole domino period (1024*1/FSamp, eg., for 5 GSP/s, this period is 200ps *1024). (The bin delay i observed was with an variation of about 30 ps).  If the external trigger is uncorrelated to the domino frequency, so, the stop positions are supposed to distribute equally to all bins? If this is true, can i calculate the bin delay via the histogram ?

   thank you~

                 Wang Jinhong

One obvious problem in your method is your statistics. If you have n hits in a bin of the histogram, the error of n is sqrt(n). So if you measure 100 hits, this is more like 100+-10 hits. If you want a better precision, you need much higher statistics. I myself never used this method, but I attach a typical nonlinearity curve running at 2 GSPS, sot hat you know what you should expect. I do some smoothing between neighbor bins so that they do not scatter too much. As you can see, the integral nonlinearity goes almost up to +-2 ns. This value is smaller at higher sampling speeds.

 - Stefan 

 Thank you, Stefan. It is really kind of you to offer suggestions or comments on our concern. 

Recently, we input a sine wave to our DRS board. DRS works at about 5 GS/s. The frequency varies from 131 MHz to 231MHz. The attached picture shows the reconstructed points of sine wave (vertical is the amplitude, horizontal axis is the point numbers). We noticed that the variation of the length of the zero crossing segments is very large. The max. length is perhaps two times the length of the min. I marked in blue color in the picture.  It means the corresponding sampling interval of the max. is two times of that of the min.  If this is true, DNL of the DRS sampling interval would be very large. We know, for uniform sampling, the length of the zero crossing segments are assumed to be uniform.  Do you have any comments? Thank you~

The length of the segments is a combination of the sampling jitter and the voltage noise. If you signal contains some noise (and all signals do) it will translate to timing jitter. The DNL of the DRS sampling interval shows a variation from the mean of typically 30%. After you correct for it, it will of course become much smaller. As I said, some people measured 10 ps timing with the DRS4 after careful timing calibration. 

Entry  Wed Sep 7 16:45:17 2011, Guillaume Blanchard, DRS4 and AD9222 

Hello,

I am designing a DAQ board with both DRS4 + AD9222 and a  FPGA to monitor.

Do I have to change the default value of O-OFS ?

Does a simple low-pass filter (series resistor + capacitor) on each AD9222 input is enough to limit the noise ?

I am planning to use the (DRS4,AD9222,FPGA) group as both a trigger and digitizing system (as shown in the DRS4 datasheet). The DRS4 will be working at 5Ghz with 8 active channels.
So each channel will have a time depth of 1/5Ghz x 1024 = 204.8ns. So, in order to miss nothing, the ADC latency + the trigger decision must be inferior to 204.8ns, am I correct ?
This leads me to implement on my board the 65Mhz version of the AD9222 as this converter has a 8 clock period latency, i.e. 123ns and it left me 81ns to perform a trigger decision ?

Cordially,

G.Blanchard

    Reply  Wed Sep 7 16:56:43 2011, Stefan Ritt, DRS4 and AD9222 

Guillaume Blanchard wrote:

Hello,

I am designing a DAQ board with both DRS4 + AD9222 and a  FPGA to monitor.

Do I have to change the default value of O-OFS ?

Does a simple low-pass filter (series resistor + capacitor) on each AD9222 input is enough to limit the noise ?

I am planning to use the (DRS4,AD9222,FPGA) group as both a trigger and digitizing system (as shown in the DRS4 datasheet). The DRS4 will be working at 5Ghz with 8 active channels.
So each channel will have a time depth of 1/5Ghz x 1024 = 204.8ns. So, in order to miss nothing, the ADC latency + the trigger decision must be inferior to 204.8ns, am I correct ?
This leads me to implement on my board the 65Mhz version of the AD9222 as this converter has a 8 clock period latency, i.e. 123ns and it left me 81ns to perform a trigger decision ?

Cordially,

G.Blanchard

I'm not so sure about the temperature stability of the default (DRS4 internal O-OFS) value, that's why I used a precision DAC in my design. But actually I never tried without. Probably the default internal value is good enough if you calibrate each chip (which you do anyhow).

Most designs use no filter between DRS4 and AD9222. Since the DRS4 output is BW limited at around 50 MHz, there is not much you win if you put a 32.5 MHz low pass there. And the PCS gets just so much simpler.

You are right with the latency of the AD9222, this is an issue. From the remaining 81 ns you loose a few going out of the FPGA, you need one or two FPGA clock cycles to make the decision, the DRS4 has also some stopping latency (maybe 10 ns). So you are at the edge. Some people use hardware comparators which are faster than the AD9222, one guy uses even directly an LVDS input of the FPGA "mis-used" as a comparator, where the comparator level (=LVDS negative input) comes from a DAC.

 

- Stefan

    Reply  Wed Sep 7 17:28:25 2011, Hannes Friederich, DRS4 and AD9222 

Guillaume Blanchard wrote:

Hello,

I am designing a DAQ board with both DRS4 + AD9222 and a  FPGA to monitor.

Do I have to change the default value of O-OFS ?

Does a simple low-pass filter (series resistor + capacitor) on each AD9222 input is enough to limit the noise ?

I am planning to use the (DRS4,AD9222,FPGA) group as both a trigger and digitizing system (as shown in the DRS4 datasheet). The DRS4 will be working at 5Ghz with 8 active channels.
So each channel will have a time depth of 1/5Ghz x 1024 = 204.8ns. So, in order to miss nothing, the ADC latency + the trigger decision must be inferior to 204.8ns, am I correct ?
This leads me to implement on my board the 65Mhz version of the AD9222 as this converter has a 8 clock period latency, i.e. 123ns and it left me 81ns to perform a trigger decision ?

Cordially,

G.Blanchard

 Like Stefan pointed out, your time constraints are quite tight. In those 81 ns, you also need to deserialize the AD9222 output. Unless you implement some really fancy input comparison logic, this will consume another 1-2 ADC clock cycles. Perhaps you should first verify that your FPGA design actually can do its job within those 81 ns. In our system, we sample at only 1-2 GHz and have enough margin to implement really complex triggers in FPGA. But the total latency (ADC + FPGA deserialization) takes 250 ns.

Depending on the application, you do need a low-pass filter. Not only because of the noise, but also in order to be able to trigger reliably. Using fast PMTs for example, you will not be able to see all pulses in full size if the bandwidth is 50 MHz and you're only sampling at 65 MSPS.

Hannes

       Reply  Fri Sep 9 09:28:57 2011, Guillaume Blanchard, DRS4 and AD9222 

Thank you for your answers,

Another question : Have you ever tried to split the differential signal at the output of the DRS4 chip ? For example to feed both an AD9222 and a diff. amplifier (followed by discriminators) ?

 

          Reply  Fri Sep 9 09:31:33 2011, Stefan Ritt, DRS4 and AD9222 

Guillaume Blanchard wrote:

Thank you for your answers,

Another question : Have you ever tried to split the differential signal at the output of the DRS4 chip ? For example to feed both an AD9222 and a diff. amplifier (followed by discriminators) ?

 

Yes. Just have a look at the schematics of the evaluation board. This is exactly what is done there.

Actually in the newest version we went one step further and put the comparator at the input of the DRS chip. This way it is active even during the readout of the DRS4 chip and we can use this as a counter to count the overall hit rate at the input.

 

- Stefan

Entry  Fri Sep 16 22:06:07 2011, Andriy Zatserklyaniy, compilation error for version 4.0.0 on linux 

Hi Stefan,

When I compiled DRS4 software version 4.0.0 on Linux (Debian Squeeze) I got this compilation error:

g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -DOS_LINUX -DHAVE_LIBUSB -DUSE_DRS_MUTEX musbstd.o mxml.o strlcpy.o DRS.o ConfigDialog.o DOFrame.o DOScreen.o DRSOsc.o MeasureDialog.o Measurement.o Osci.o InfoDialog.o DisplayDialog.o AboutDialog.o EPThread.o rb.o main.o -o drsosc -lpthread -lutil -lusb -pthread   -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8
DOFrame.o: In function `DOFrame':
/srv/zatserkl/work/drs4/drs-4.0.0/src/DOFrame.cpp:237: undefined reference to `TriggerDialog::TriggerDialog(wxWindow*)'
/srv/zatserkl/work/drs4/drs-4.0.0/src/DOFrame.cpp:237: undefined reference to `TriggerDialog::TriggerDialog(wxWindow*)'
collect2: ld returned 1 exit status
make: *** [drsosc] Error 1

 

To fix it I added TriggerDialog.o into CPP_OBJ line of the Makefile:

 

CPP_OBJ       = DRS.o ConfigDialog.o DOFrame.o DOScreen.o DRSOsc.o MeasureDialog.o Measurement.o Osci.o InfoDialog.o DisplayDialog.o AboutDialog.o EPThread.o rb.o TriggerDialog.o

 

Best,

Andriy.

    Reply  Mon Sep 19 08:53:22 2011, Stefan Ritt, compilation error for version 4.0.0 on linux 

Andriy Zatserklyaniy wrote:

To fix it I added TriggerDialog.o into CPP_OBJ line of the Makefile:

Thanks. I added your fix to the current 4.0.0 distribution.

- Stefan 

Entry  Sat Oct 15 04:45:25 2011, Aurelien Bouvier, DRS4 eval board: readout rate 

Hi,

Our setup uses a DRS4 evaluation board (version 2.0).

Although we trigger the board at a rate of ~4kHz (on channel2), readout through USB2 is only happening at a rate of ~125Hz.

After some investigation, we could pin down that it is due to the time it takes to complete the following commands: musb_write() and musb_read() which both take ~150 microsecond to complete. Because they are called multiple times, reading out 1 trigger takes ~8 millisecond which explains the 125Hz we're seeing.

Is ~150 us to complete a musb_read()/musb_write() command expected?

Is there any way we could speed up the readout rate of the DRS4 board so that data acquisition through USB2 is closer to our trigger rate of 4kHz?

Any feedback you might have on this topic would be greatly appreciated.

Many thanks,

Aurelien

    Reply  Sat Oct 22 00:40:02 2011, Stefan Ritt, DRS4 eval board: readout rate 

Aurelien Bouvier wrote:

Hi,

Our setup uses a DRS4 evaluation board (version 2.0).

Although we trigger the board at a rate of ~4kHz (on channel2), readout through USB2 is only happening at a rate of ~125Hz.

After some investigation, we could pin down that it is due to the time it takes to complete the following commands: musb_write() and musb_read() which both take ~150 microsecond to complete. Because they are called multiple times, reading out 1 trigger takes ~8 millisecond which explains the 125Hz we're seeing.

Is ~150 us to complete a musb_read()/musb_write() command expected?

Is there any way we could speed up the readout rate of the DRS4 board so that data acquisition through USB2 is closer to our trigger rate of 4kHz?

Any feedback you might have on this topic would be greatly appreciated.

Many thanks,

Aurelien

With version 4 of the DRSOsc program and a decent computer, you should be able to achieve something close to 500 Hz, but that's the limit. The board is for evaluation purposes of the chip, not for production data acquisition. The main limit comes from USB2, which is limited to ~25 MB/sec. We are in the process of designing a new board with Gigabit Ethernet readout, with which you should be able to get your 4 kHz. But this board will not be ready before spring. There is also a VME board by CAEN in Italy which sits in a VME crate. This board is also much faster than the USB board. Here is the link:

http://www.caen.it/csite/CaenProfList.jsp?parent=13&Type=WOCateg&prodsupp=home

 

Entry  Sun Oct 23 23:32:28 2011, Hao Huan, Phase Shift for ADC Readout 

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?

    Reply  Mon Oct 24 10:30:15 2011, Stefan Ritt, Phase Shift for ADC Readout 

Hao Huan wrote:

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.

Entry  Mon Oct 31 09:15:02 2011, Zhongwei Du, How to link PMT 

I want to measure the signal from PMT . But it is a current signal, should i just put a series resistance, or use a amplifier to convert it to voltage signal before drs4?  

Can you give me some advice ? 

    Reply  Tue Nov 1 11:07:02 2011, Stefan Ritt, How to link PMT 

Zhongwei Du wrote:

I want to measure the signal from PMT . But it is a current signal, should i just put a series resistance, or use a amplifier to convert it to voltage signal before drs4?  

Can you give me some advice ? 

The evaluation board has a 50 Ohm termination resistor, which already converts your current into a voltage signal. If the resulting signal is too low (<20 mV) you can put in an amplifier or raise the HV of your PMT (inside the valid range given by its datasheet of course).

- Stefan 

Entry  Thu Apr 14 18:23:53 2011, Bob Hirosky, Fixes to DOScreen.cpp for recent built on linux 
Hello,

I was just building version 3.1.0 and ran into some problems in DOScreen.cpp.  Basically the conversions from
char* to wxString were generating "ambiguous overload" errors (in gcc 4.4.3, wx-2.8)

The simple fix is given in  the following diff output.

Cheers,

Bob

diff drs-3.1.0_o/src/DOScreen.cpp drs-3.1.0/src
237c237
<      wxst = wxString(m_frame->GetOsci()->GetDebugMsg(),wxConvUTF8);  //BH
---
>       wxst = m_frame->GetOsci()->GetDebugMsg();
246c246
<       wxst = wxString(m_debugMsg,wxConvUTF8);  //BH
---
>       wxst = m_debugMsg;
477c477
<     wxst = wxString("AUTO",wxConvUTF8); //BH
---
>          wxst = "AUTO";
479c479
<     wxst = wxString("TRIG?",wxConvUTF8);  //BH
---
>          wxst = "TRIG?";
 
    Reply  Fri Apr 15 08:28:54 2011, Stefan Ritt, Fixes to DOScreen.cpp for recent built on linux 
> Hello,
> 
> I was just building version 3.1.0 and ran into some problems in DOScreen.cpp.  Basically the conversions from
> char* to wxString were generating "ambiguous overload" errors (in gcc 4.4.3, wx-2.8)
> 
> The simple fix is given in  the following diff output.
> 
> Cheers,
> 
> Bob
> 
> diff drs-3.1.0_o/src/DOScreen.cpp drs-3.1.0/src
> 237c237
> <      wxst = wxString(m_frame->GetOsci()->GetDebugMsg(),wxConvUTF8);  //BH
> ---
> >       wxst = m_frame->GetOsci()->GetDebugMsg();
> 246c246
> <       wxst = wxString(m_debugMsg,wxConvUTF8);  //BH
> ---
> >       wxst = m_debugMsg;
> 477c477
> <     wxst = wxString("AUTO",wxConvUTF8); //BH
> ---
> >          wxst = "AUTO";
> 479c479
> <     wxst = wxString("TRIG?",wxConvUTF8);  //BH
> ---
> >          wxst = "TRIG?";
>  

Thanks for mentioning this. I always overlook this because I develop under Windows where this warning does not show 
up. I fixed that in the current version. Usually I just use _T() instead wxString() because this is shorter and 
recommended by the developers.

Cheers, Stefan.
    Reply  Fri Dec 9 17:45:48 2011, Michael Büker, Fixes to DOScreen.cpp for recent built on linux 
> I was just building version 3.1.0 and ran into some problems in DOScreen.cpp.  Basically the conversions from
> char* to wxString were generating "ambiguous overload" errors (in gcc 4.4.3, wx-2.8)
> 
> The simple fix is given in  the following diff output.

Today, I ran into the same problem and was happy to find your fix. I've incorporated it into a unified diff file,
that can easily be applied with the patch program by saving it into a file ('drsosc-3.1.0-wxfix.patch', say), and
in the drs-3.1.0 directory running:

patch -1 < drsosc-3.1.0-wxfix.patch

This is the file:

--- src/DOScreen.cpp.orig	2011-12-09 15:49:48.682201902 +0100
+++ src/DOScreen.cpp		2011-12-09 15:51:45.666000111 +0100
@@ -234,7 +234,7 @@ void DOScreen::DrawWaveform(wxDC& dc, wx
 
    // display optional debug messages
    if (*m_frame->GetOsci()->GetDebugMsg()) {
-      wxst = m_frame->GetOsci()->GetDebugMsg();
+      wxst = wxString(m_frame->GetOsci()->GetDebugMsg(),wxConvUTF8);
       dc.SetPen(wxPen(*wxLIGHT_GREY, 1, wxSOLID));
       dc.SetBrush(*wxGREEN);
       dc.SetTextForeground(*wxBLACK);
@@ -243,7 +243,7 @@ void DOScreen::DrawWaveform(wxDC& dc, wx
       dc.DrawText(wxst, m_x1+4, m_y1+2);
    }
    if (m_debugMsg[0]) {
-      wxst = m_debugMsg;
+      wxst = wxString(m_debugMsg,wxConvUTF8);
       dc.SetPen(wxPen(*wxLIGHT_GREY, 1, wxSOLID));
       dc.SetBrush(*wxGREEN);
       dc.SetTextForeground(*wxBLACK);
@@ -474,9 +474,9 @@ void DOScreen::DrawWaveform(wxDC& dc, wx
    if (m_osci->GetNumberOfBoards() && m_osci->IsIdle()) {
       dc.SetTextForeground(*wxGREEN);
       if (m_osci->GetTriggerMode() == TM_AUTO)
-         wxst = "AUTO";
+         wxst = wxString("AUTO",wxConvUTF8);
       else
-         wxst = "TRIG?";
+         wxst = wxString("TRIG?",wxConvUTF8);
       dc.GetTextExtent(wxst, &w, &h);
       dc.DrawText(wxst, m_x2 - w - 2, m_y1 + 1);
    }
Entry  Mon Dec 12 16:43:04 2011, Stefan Ritt, DC coupled DRS4 input stage DRS4_front_end_DC.pdf

In the attachement you will find a working DC-coupled input stage to the DRS4 chip. The bandwidth of this design is about 700 MHz, the gain is 1.

The upper version does not have an additional input buffer. This is not a very "clean" design, since the differential driver has an input impedance of 150 Ohm, which together with the 75 Ohm termination resistor gives about 50 Ohm termination. 

The lover version has an additional input buffer, which nicely decouples the input from the differential driver, so a proper 50 Ohm termination can be used at the cost of additional power for that buffer.

The COM common mode voltage and the OFS voltage have to be set according to the required input range, so that ranges such as 0V...1V, -0.5V...+0.5V, -1V...0V can be used. The COM voltage can be high impedance (simple resistor divider), while the OFS voltage needs to be low impedance (fast active buffer). The analog switch ADG918 can be used to digitize a precise calibration voltage CAL+, which can then be used for precise gain calibration of the DRS4 sampling cells.

Entry  Wed Dec 14 00:44:37 2011, Hao Huan, Synchronization Delay in the Firmware for 8051 Controller 

Hi Stefan,

    I have a question regarding the DRS 4 evaluation board firmware for the 8051 controller embedded in the CY7C68013 USB chip: on the board the controller is running at 12 MHz and the FIFO interface of the USB chip is running at 30 MHz, so the number of delay cycles for synchronization as defined in fx2sdly.h should be (3*12000+5*30000-1)/(2*30000)=3, but the actual number used in drs_eval.c is (3*12000+5*48000-1)/(2*48000)=2, so there is a mismatch between the IFCLK frequency used in this calculation and the actual IFCLK frequency configured. Am I misunderstanding something or is there an explanation for that?

 

    Thanks,

Hao Huan

    Reply  Wed Dec 14 08:55:29 2011, Stefan Ritt, Synchronization Delay in the Firmware for 8051 Controller 

Hao Huan wrote:

Hi Stefan,

    I have a question regarding the DRS 4 evaluation board firmware for the 8051 controller embedded in the CY7C68013 USB chip: on the board the controller is running at 12 MHz and the FIFO interface of the USB chip is running at 30 MHz, so the number of delay cycles for synchronization as defined in fx2sdly.h should be (3*12000+5*30000-1)/(2*30000)=3, but the actual number used in drs_eval.c is (3*12000+5*48000-1)/(2*48000)=2, so there is a mismatch between the IFCLK frequency used in this calculation and the actual IFCLK frequency configured. Am I misunderstanding something or is there an explanation for that?

 

    Thanks,

Hao Huan

You are right. The SYNCDELAY should contain three wait cycles. I kind of remember that this delay is not very critical. That might be the reason why the system works even with the wrong delay reliably. 

Entry  Thu Jan 19 23:26:26 2012, Heejong Kim, drs_exam.cpp for evaluation board version 4 

Hello,

I'm using DRS4 evaluation board version4 in Linux (Scientific Linux 5).

Version4 software (drs-4.0.0) was installed without any troubles.

The oscilloscope interfrace program (drsosc) is working fine with version4 software.

But when I tried drs_exam program, it doesn't work as expected.

(500 mV positive (width 50ns)  pulse is connected to Ch#1).

It keeps waiting trigger in the first event.

In the previous version (board/software drs-3.0.0), drs_exam program worked well.

I'm wondering if anybody is using drs_exam with V4 evaluation board.

Any comments/help would be welcomed.

 

Thanks,

Heejong

    Reply  Fri Jan 20 08:09:38 2012, Stefan Ritt, drs_exam.cpp for evaluation board version 4 drs_exam.cpp

Heejong Kim wrote:

Hello,

I'm using DRS4 evaluation board version4 in Linux (Scientific Linux 5).

Version4 software (drs-4.0.0) was installed without any troubles.

The oscilloscope interfrace program (drsosc) is working fine with version4 software.

But when I tried drs_exam program, it doesn't work as expected.

(500 mV positive (width 50ns)  pulse is connected to Ch#1).

It keeps waiting trigger in the first event.

In the previous version (board/software drs-3.0.0), drs_exam program worked well.

I'm wondering if anybody is using drs_exam with V4 evaluation board.

The issue is that the V4 board has new trigger capabilities (such as coincidences between two channels) which require a slightly different configuration. Here it the new code:

 

   /* use following lines to enable hardware trigger on CH1 at 50 mV positive edge */
   if (b->GetBoardType() == 8) {     // Evaluaiton Board V4
      b->EnableTrigger(1, 0);           // enable hardware trigger
      b->SetTriggerSource(1<<0);        // set CH1 as source
   } else {                          // Evaluation Board V3
      b->EnableTrigger(0, 1);           // lemo off, analog trigger on
      b->SetTriggerSource(0);           // use CH1 as source
   }

The complete file is attached. Please try again with the new code. Probably next week I will make a new software release (including a Mac version of all programs) which will contain the new code. Sorry for any inconvenience.

Best regards,
Stefan

 

 

 

       Reply  Fri Jan 20 23:50:39 2012, Heejong Kim, drs_exam.cpp for evaluation board version 4 

Stefan Ritt wrote:

Heejong Kim wrote:

Hello,

I'm using DRS4 evaluation board version4 in Linux (Scientific Linux 5).

Version4 software (drs-4.0.0) was installed without any troubles.

The oscilloscope interfrace program (drsosc) is working fine with version4 software.

But when I tried drs_exam program, it doesn't work as expected.

(500 mV positive (width 50ns)  pulse is connected to Ch#1).

It keeps waiting trigger in the first event.

In the previous version (board/software drs-3.0.0), drs_exam program worked well.

I'm wondering if anybody is using drs_exam with V4 evaluation board.

The issue is that the V4 board has new trigger capabilities (such as coincidences between two channels) which require a slightly different configuration. Here it the new code:

 

   /* use following lines to enable hardware trigger on CH1 at 50 mV positive edge */
   if (b->GetBoardType() == 8) {     // Evaluaiton Board V4
      b->EnableTrigger(1, 0);           // enable hardware trigger
      b->SetTriggerSource(1<<0);        // set CH1 as source
   } else {                          // Evaluation Board V3
      b->EnableTrigger(0, 1);           // lemo off, analog trigger on
      b->SetTriggerSource(0);           // use CH1 as source
   }

The complete file is attached. Please try again with the new code. Probably next week I will make a new software release (including a Mac version of all programs) which will contain the new code. Sorry for any inconvenience.

Best regards,
Stefan

 

 

 

Hello Stefan,

Thanks for your prompt reply.

drs_exam is working now after modification as above.

By some trials, I found that external trigger is possible by 'b->EnableTrigger(1,0); b->SetTriggerSource(1<<4);'

Best,

Heejong

 

 

Entry  Thu Jan 26 09:12:03 2012, Ravindra Raghunath Shinde, DRS4 Rev2.0 for analog pulse counting 

Hello,

We are using DRS4 Rev.2.0 board.

We want to measure number of pulses generated  by charge particle detector. These negative going analog pulses are very fast having rise time about 2nS.

We want keep threshold level to -20mV. We expected pulse rate to be about 100 to 200 Hz.

I need help to implement this in  current DRS board with  dead time free operation.

 

    Reply  Thu Jan 26 09:15:42 2012, Stefan Ritt, DRS4 Rev2.0 for analog pulse counting 

Ravindra Raghunath Shinde wrote:

Hello,

We are using DRS4 Rev.2.0 board.

We want to measure number of pulses generated  by charge particle detector. These negative going analog pulses are very fast having rise time about 2nS.

We want keep threshold level to -20mV. We expected pulse rate to be about 100 to 200 Hz.

I need help to implement this in  current DRS board with  dead time free operation.

 

If you just want to count pulses, you do not need a DRS board. Just use a discriminator and a counter, that's much simpler. The DRS board is not dead time free. 

       Reply  Thu Jan 26 09:44:34 2012, Ravindra Raghunath Shinde, DRS4 Rev2.0 for analog pulse counting 

Stefan Ritt wrote:

Ravindra Raghunath Shinde wrote:

Hello,

We are using DRS4 Rev.2.0 board.

We want to measure number of pulses generated  by charge particle detector. These negative going analog pulses are very fast having rise time about 2nS.

We want keep threshold level to -20mV. We expected pulse rate to be about 100 to 200 Hz.

I need help to implement this in  current DRS board with  dead time free operation.

 

If you just want to count pulses, you do not need a DRS board. Just use a discriminator and a counter, that's much simpler. The DRS board is not dead time free. 

 Thanks for your prompt reply.

Along with pulse rate  we also want see pulse shape as well as charge measurements. That is why we are exploring this option with our existing DRS Set-up.

 

          Reply  Thu Jan 26 09:49:38 2012, Stefan Ritt, DRS4 Rev2.0 for analog pulse counting 

Ravindra Raghunath Shinde wrote:

Stefan Ritt wrote:

Ravindra Raghunath Shinde wrote:

Hello,

We are using DRS4 Rev.2.0 board.

We want to measure number of pulses generated  by charge particle detector. These negative going analog pulses are very fast having rise time about 2nS.

We want keep threshold level to -20mV. We expected pulse rate to be about 100 to 200 Hz.

I need help to implement this in  current DRS board with  dead time free operation.

 

If you just want to count pulses, you do not need a DRS board. Just use a discriminator and a counter, that's much simpler. The DRS board is not dead time free. 

 Thanks for your prompt reply.

Along with pulse rate  we also want see pulse shape as well as charge measurements. That is why we are exploring this option with our existing DRS Set-up.

 

I understand that. But still the board has some dead time which is dominated by the USB data transfer speed.

There is a way to perform the counting dead time free, but that requires the V4 board, which has a hardware comparator on all four channels (The V2 board has only one comparator and a multiplexer). The output of these comparators go directly to the FPGA, which can then trigger on these signals. In principle one could implement a hardware counter in the FPGA, which works practically dead time free. But this requires a new firmware which has to be written. Either you do it yourself using the Xilinx development tools, or you wait until I find some time to implement this, which could take a couple of weeks or even months.

Best regards,

Stefan 

             Reply  Thu Jan 26 10:05:57 2012, Ravindra Raghunath Shinde, DRS4 Rev2.0 for analog pulse counting 

Stefan Ritt wrote:

Ravindra Raghunath Shinde wrote:

Stefan Ritt wrote:

Ravindra Raghunath Shinde wrote:

Hello,

We are using DRS4 Rev.2.0 board.

We want to measure number of pulses generated  by charge particle detector. These negative going analog pulses are very fast having rise time about 2nS.

We want keep threshold level to -20mV. We expected pulse rate to be about 100 to 200 Hz.

I need help to implement this in  current DRS board with  dead time free operation.

 

If you just want to count pulses, you do not need a DRS board. Just use a discriminator and a counter, that's much simpler. The DRS board is not dead time free. 

 Thanks for your prompt reply.

Along with pulse rate  we also want see pulse shape as well as charge measurements. That is why we are exploring this option with our existing DRS Set-up.

 

I understand that. But still the board has some dead time which is dominated by the USB data transfer speed.

There is a way to perform the counting dead time free, but that requires the V4 board, which has a hardware comparator on all four channels (The V2 board has only one comparator and a multiplexer). The output of these comparators go directly to the FPGA, which can then trigger on these signals. In principle one could implement a hardware counter in the FPGA, which works practically dead time free. But this requires a new firmware which has to be written. Either you do it yourself using the Xilinx development tools, or you wait until I find some time to implement this, which could take a couple of weeks or even months.

Best regards,

Stefan 

 Thank you very much.

With regards,

Ravindra R. Shinde

Entry  Tue Jan 31 08:10:37 2012, Stefan Ritt, IEEE Real Time 2012 Call for Abstracts 

Hello,

I'm co-organizing the upcoming Real Time Conference, which covers also fields of waveform processing and sampling, so it might be interesting for people working with the DRS4 chip. If you have recent results, you could also consider to send an abstract to this conference.  It will be nicely located in Berkeley, California. We plan excursions to San Francisco and to Napa Valley.

Best regards,

Stefan Ritt


18th Real Time Conference
June 11 – 15, 2012
Berkeley, CA

We invite you to the Hotel Shattuck Plaza in downtown Berkeley, California for
the 2012 Real-Time Conference (RT2012).   It will take place Monday, June 11
through Friday, June 15, 2012, with optional pre-conference tutorials Saturday
and Sunday, June 9-10.

Like the previous editions, RT2012 will be a multidisciplinary conference
devoted to the latest developments on realtime techniques in the fields of
plasma and nuclear fusion, particle physics, nuclear physics and astrophysics,
space science, accelerators, medical physics, nuclear power instrumentation and
other radiation instrumentation.

Abstract submission is open as of 18 January (deadline 2 March). Please visit

http://www.npss-confs.org/rtc/welcome.asp?flag=44675.77&Retry=1 to submit an

abstract.

Call for Abstracts 

RT 2012 is an interdisciplinary conference on realtime data acquisition and
computing applications in the physical sciences. These applications include:

* High energy physics 
* Nuclear physics 
* Astrophysics and astroparticle physics 
* Nuclear fusion 
* Medical physics 
* Space instrumentation 
* Nuclear power instrumentation 
* Realtime security and safety 
* General Radiation Instrumentation 

Specific topics include (but are certainly not limited to) the list shown below.
We welcome correspondence to see how your research fits our venue.   

Key Dates

* Abstract submission opened:  January 18, 2012 
* Abstract deadline:  March 2, 2012 
* Program available: April 2 

Suggested Topics

* Realtime system architectures 
* Intelligent signal processing 
* Programmable devices 
* Fast data transfer links and networks 
* Trigger systems 
* Data acquisition 
* Processing farms 
* Control, monitoring, and test systems 
* Upgrades 
* Emerging realtime technologies 
* New standards 
* Realtime safety and security 
* Feedback on experiences 

Contact Information

If you have a question or wish to opt in for occasional e-mail updates about
RT2012, send us a message at RT2012@lbl.gov. To view full conference
information, visit http://rt2012.lbl.gov/index.html

Entry  Sat Feb 4 11:59:26 2012, Zhongwei Du, what sort of detectors for physical experiment the DRS4 used? 

Hello.

We are designing a waveform sampling board for Si strip array detector ,whose rise time is less than 10 ns, which makes we doubt whether the DRS4 can do more accurate than traditional charge integral circuit for charge measuring.

So we need to know what sort of detectors for physical experiment the DRS4 has been used in?

Can you give me some information? For example, Si strip array detector or CsI scintillator r ball detector ? PMT or APD ?

    Reply  Mon Feb 6 08:15:38 2012, Stefan Ritt, what sort of detectors for physical experiment the DRS4 used? 

Zhongwei Du wrote:

Hello.

We are designing a waveform sampling board for Si strip array detector ,whose rise time is less than 10 ns, which makes we doubt whether the DRS4 can do more accurate than traditional charge integral circuit for charge measuring.

So we need to know what sort of detectors for physical experiment the DRS4 has been used in?

Can you give me some information? For example, Si strip array detector or CsI scintillator r ball detector ? PMT or APD ?

DRS4 is used for PMTs and APDs. The minimal rise/fall time which can be recorded with the DRS4 on the evaluation boards is about 0.8ns (see elog:84). Concerning charge measurement, it depends on your integration time. If your signal is for example 20ns and you sample with 5 GSPS, you get actually 100 samples. You digitize with 12 bits, but the S/N ratio is more like 11.5 bits. But since you have 100 samples, the accuracy of the measurement scales with sqrt(100)=10. So you have more like 11.5+3 bits = 14-15 bits, or a SNR of 20'000. Now your signal usually does not have an amplitude of 1V, will be more like 100mV or so, in which case your SNR goes to 2000. But this still gives you a resolution of 1/2000 = 0.5 per mille.

We did tests with a Ge detector for spectroscopy applications, where we used a shaping time of 2 micro seconds, both with traditional electronics and the DRS4, integrating the signal over 2 micro seconds. Both gave a resolution of about 0.4%, indicating that the resolution was not limited by the DRS but by the detector.

Best regards,

Stefan 

Entry  Wed Feb 15 18:08:13 2012, Yuji Iwai, Evaluation Board v4 Trigger/Clock Connectors 

Quick question - what type of connectors are used for the trigger and clock in/out on the v4 eval board?

Entry  Mon Apr 23 10:38:51 2012, Guillaume Blanchard, DRS4 Initialization 

Hello,

I am writing a VHDL code to drive a DRS4 chip.

In order to configure the DRS4 chip, I have to set the "Config Register" and the "Write Shift Register" then ... (I do not plan to use simultaneous WR and R so I guess the Write Config Reg. is not needed)

My question is :

When do we have to perform a "Read Shift Register Initialization" ?

Every time before a full read-out, or juste once after a DRS4 reset ?

Further more, is this initialization needed for the ROI mode ?

And at last do the level of the DENABLE and DWRITE signals matter for the "Read Shift Register Initialization" ?

(To sum up : what is the purpose of the Read Shift Register and how does it work ?)

Cordially,

G.Blanchard.

    Reply  Wed Apr 25 13:42:37 2012, Stefan Ritt, DRS4 Initialization 

Guillaume Blanchard wrote:

Hello,

I am writing a VHDL code to drive a DRS4 chip.

In order to configure the DRS4 chip, I have to set the "Config Register" and the "Write Shift Register" then ... (I do not plan to use simultaneous WR and R so I guess the Write Config Reg. is not needed)

My question is :

When do we have to perform a "Read Shift Register Initialization" ?

Every time before a full read-out, or juste once after a DRS4 reset ?

Further more, is this initialization needed for the ROI mode ?

And at last do the level of the DENABLE and DWRITE signals matter for the "Read Shift Register Initialization" ?

(To sum up : what is the purpose of the Read Shift Register and how does it work ?)

Cordially,

G.Blanchard.

There are two readout modes "Full Readout Mode" and  "ROI mode". 

In the Full Readout Mode, the Read Shift Register has to be initialized before the first readout by applying the sequence shown in Figure 11 in the data sheet. This clears the full shift register and sets the first cell to "1". In principle in the following events one applies each time 1024 clocks. Since the shift register is circula, the single "1" rotates through the shift register and is at the same position after 1024 clocks. So in principle the register does not have to be re-initialized. To be hones I have never tried this myself, so I'm not completely sure if that works.

In the ROI mode, you initialize the Read Shift Register by a single RSRLOAD pulse as shown in Figure 15. Since the inverter chain stops at different positions in each event, this pulse has to be applied before each event. The SROUT bits will then tell you where the inverter chain has been stopped.

Most people I know of use the ROI mode, since the initialization is much simpler (just a single pulse).

Best regards,

Stefan

Entry  Tue Mar 20 16:23:33 2012, Martin Petriska, triger for measuring time between pulses in channels 

 I have two BaF2 detectors with PMT connected to Ch1 and Ch2. At this time Im using external triger module to start DRS4. My evalution board is version 3 so I have no possibility to trigger on two or more pulses occurence on different channels. But I have this idea, trigger with analog trigger on channel 1 (start detector) will start measurement on all channels. After that using FPGA inside EVM to look if some value in Ch2 is bigger as treshold value for example 0,5V and if yes then send data by USB to PC, if signal in Ch2 is lower then restart measurement and wait on triger in Ch1. This way I want to eliminate false data transfer throw USB. Is this possible to implement it into DRS4 evaluation board firmware ?

Thanks.

    Reply  Tue Mar 20 16:33:50 2012, Stefan Ritt, triger for measuring time between pulses in channels 

Martin Petriska wrote:

 I have two BaF2 detectors with PMT connected to Ch1 and Ch2. At this time Im using external triger module to start DRS4. My evalution board is version 3 so I have no possibility to trigger on two or more pulses occurence on different channels. But I have this idea, trigger with analog trigger on channel 1 (start detector) will start measurement on all channels. After that using FPGA inside EVM to look if some value in Ch2 is bigger as treshold value for example 0,5V and if yes then send data by USB to PC, if signal in Ch2 is lower then restart measurement and wait on triger in Ch1. This way I want to eliminate false data transfer throw USB. Is this possible to implement it into DRS4 evaluation board firmware ?

Thanks.

It is muuuuch easier to upgrade to a V4 board!

Modification of firmware is not so easy. You have to learn and understand VHDL. Then, you have to add additional registers for this thresholds, which requires modification of the C library as well. The data inside the evaluation boards is not yet calibrated (this is only done on the C library), so you have an uncertainty of 30-40mV in this data. 

       Reply  Wed Mar 21 09:33:00 2012, Martin Petriska, triger for measuring time between pulses in channels 

Stefan Ritt wrote:

Martin Petriska wrote:

 I have two BaF2 detectors with PMT connected to Ch1 and Ch2. At this time Im using external triger module to start DRS4. My evalution board is version 3 so I have no possibility to trigger on two or more pulses occurence on different channels. But I have this idea, trigger with analog trigger on channel 1 (start detector) will start measurement on all channels. After that using FPGA inside EVM to look if some value in Ch2 is bigger as treshold value for example 0,5V and if yes then send data by USB to PC, if signal in Ch2 is lower then restart measurement and wait on triger in Ch1. This way I want to eliminate false data transfer throw USB. Is this possible to implement it into DRS4 evaluation board firmware ?

Thanks.

It is muuuuch easier to upgrade to a V4 board!

Modification of firmware is not so easy. You have to learn and understand VHDL. Then, you have to add additional registers for this thresholds, which requires modification of the C library as well. The data inside the evaluation boards is not yet calibrated (this is only done on the C library), so you have an uncertainty of 30-40mV in this data. 

Ok, except this, I would have a question regarding to the new trigering posibility in V4 board. At this time, I am using Ztec ZT4612 which has some pattern triger posibility. Output from this card is used as an external trigger. Regarding this I have found a problem. Pulses from PMT have about 5-8 ns width. But I need to measure time diferences between pulses in range from 0-50ns. Problem is, that coincidence between pulses is working only on short pulse area (5-8ns) when they are overlapped. Additionaly the result histogram of time diferences is proportional to the pulse shapes. I solve this problem enabling 20MHz LPF filter in ZT4612, so the pulses are wider and overlaped on larger area. But, how it is with the V4 board? Will it trigger if I have for example one 5ns pulse on begiinning of CH1 and second pulse for example 50 ns later on Ch2 with the same probability when pulses are in the same time position?

          Reply  Wed Mar 21 09:39:33 2012, Stefan Ritt, triger for measuring time between pulses in channels 

Martin Petriska wrote:

Stefan Ritt wrote:

Martin Petriska wrote:

 I have two BaF2 detectors with PMT connected to Ch1 and Ch2. At this time Im using external triger module to start DRS4. My evalution board is version 3 so I have no possibility to trigger on two or more pulses occurence on different channels. But I have this idea, trigger with analog trigger on channel 1 (start detector) will start measurement on all channels. After that using FPGA inside EVM to look if some value in Ch2 is bigger as treshold value for example 0,5V and if yes then send data by USB to PC, if signal in Ch2 is lower then restart measurement and wait on triger in Ch1. This way I want to eliminate false data transfer throw USB. Is this possible to implement it into DRS4 evaluation board firmware ?

Thanks.

It is muuuuch easier to upgrade to a V4 board!

Modification of firmware is not so easy. You have to learn and understand VHDL. Then, you have to add additional registers for this thresholds, which requires modification of the C library as well. The data inside the evaluation boards is not yet calibrated (this is only done on the C library), so you have an uncertainty of 30-40mV in this data. 

Ok, except this, I would have a question regarding to the new trigering posibility in V4 board. At this time, I am using Ztec ZT4612 which has some pattern triger posibility. Output from this card is used as an external trigger. Regarding this I have found a problem. Pulses from PMT have about 5-8 ns width. But I need to measure time diferences between pulses in range from 0-50ns. Problem is, that coincidence between pulses is working only on short pulse area (5-8ns) when they are overlapped. Additionaly the result histogram of time diferences is proportional to the pulse shapes. I solve this problem enabling 20MHz LPF filter in ZT4612, so the pulses are wider and overlaped on larger area. But, how it is with the V4 board? Will it trigger if I have for example one 5ns pulse on begiinning of CH1 and second pulse for example 50 ns later on Ch2 with the same probability when pulses are in the same time position?

No. 

             Reply  Wed Jun 20 10:40:21 2012, Ivan Petrov, triger for measuring time between pulses in channels 

Stefan Ritt wrote:

Martin Petriska wrote:

Stefan Ritt wrote:

Martin Petriska wrote:

 I have two BaF2 detectors with PMT connected to Ch1 and Ch2. At this time Im using external triger module to start DRS4. My evalution board is version 3 so I have no possibility to trigger on two or more pulses occurence on different channels. But I have this idea, trigger with analog trigger on channel 1 (start detector) will start measurement on all channels. After that using FPGA inside EVM to look if some value in Ch2 is bigger as treshold value for example 0,5V and if yes then send data by USB to PC, if signal in Ch2 is lower then restart measurement and wait on triger in Ch1. This way I want to eliminate false data transfer throw USB. Is this possible to implement it into DRS4 evaluation board firmware ?

Thanks.

It is muuuuch easier to upgrade to a V4 board!

Modification of firmware is not so easy. You have to learn and understand VHDL. Then, you have to add additional registers for this thresholds, which requires modification of the C library as well. The data inside the evaluation boards is not yet calibrated (this is only done on the C library), so you have an uncertainty of 30-40mV in this data. 

Ok, except this, I would have a question regarding to the new trigering posibility in V4 board. At this time, I am using Ztec ZT4612 which has some pattern triger posibility. Output from this card is used as an external trigger. Regarding this I have found a problem. Pulses from PMT have about 5-8 ns width. But I need to measure time diferences between pulses in range from 0-50ns. Problem is, that coincidence between pulses is working only on short pulse area (5-8ns) when they are overlapped. Additionaly the result histogram of time diferences is proportional to the pulse shapes. I solve this problem enabling 20MHz LPF filter in ZT4612, so the pulses are wider and overlaped on larger area. But, how it is with the V4 board? Will it trigger if I have for example one 5ns pulse on begiinning of CH1 and second pulse for example 50 ns later on Ch2 with the same probability when pulses are in the same time position?

No. 

Hello. I need to digitize pulses from two PMT. After pulse on first PMT I have to save all pulses from second PMT in range 200 ns (and starting pulse from the first, and time range between pulse from 1st PMT and pulses from 2nd PMT). Is it possible with DRS evaluation board?

                Reply  Wed Jun 20 12:45:05 2012, Stefan Ritt, triger for measuring time between pulses in channels 

Ivan Petrov wrote:

 

Hello. I need to digitize pulses from two PMT. After pulse on first PMT I have to save all pulses from second PMT in range 200 ns (and starting pulse from the first, and time range between pulse from 1st PMT and pulses from 2nd PMT). Is it possible with DRS evaluation board?

If you run at 2 GSPS, you have a time window of 500 ns like on an oscilloscope. If you trigger on 1st PMT, you will get the traces of all 4 inputs for the next 500 ns. So I guess this is what you want. 

                   Reply  Wed Jun 20 14:36:01 2012, Ivan Petrov, triger for measuring time between pulses in channels 

Stefan Ritt wrote:

Ivan Petrov wrote:

 

Hello. I need to digitize pulses from two PMT. After pulse on first PMT I have to save all pulses from second PMT in range 200 ns (and starting pulse from the first, and time range between pulse from 1st PMT and pulses from 2nd PMT). Is it possible with DRS evaluation board?

If you run at 2 GSPS, you have a time window of 500 ns like on an oscilloscope. If you trigger on 1st PMT, you will get the traces of all 4 inputs for the next 500 ns. So I guess this is what you want. 

 Ok. And, If I understand correctly, the main bottleneck in data readout is USB. I.e., theoretically maximum readout rate is 500 Hz. Is it true?

                      Reply  Wed Jun 20 14:44:38 2012, Stefan Ritt, triger for measuring time between pulses in channels 

Ivan Petrov wrote:

Stefan Ritt wrote:

Ivan Petrov wrote:

 

Hello. I need to digitize pulses from two PMT. After pulse on first PMT I have to save all pulses from second PMT in range 200 ns (and starting pulse from the first, and time range between pulse from 1st PMT and pulses from 2nd PMT). Is it possible with DRS evaluation board?

If you run at 2 GSPS, you have a time window of 500 ns like on an oscilloscope. If you trigger on 1st PMT, you will get the traces of all 4 inputs for the next 500 ns. So I guess this is what you want. 

 Ok. And, If I understand correctly, the main bottleneck in data readout is USB. I.e., theoretically maximum readout rate is 500 Hz. Is it true?

On the evaluation board, yes. This board is not optimized for high readout rate. If you do your own electronics, like GBit Ethernet, you could be much faster. 

                         Reply  Sat Jun 23 00:29:52 2012, Andrey Kuznetsov, triger for measuring time between pulses in channels 

Stefan Ritt wrote:

On the evaluation board, yes. This board is not optimized for high readout rate. If you do your own electronics, like GBit Ethernet, you could be much faster. 

 What is the readout rate via GBit Ethernet that you have achieved?

Where is the bottleneck in ethernet?

What is the proposed scheme by which the GBit Ethernet will be implemented, will the DRS4 Eval Board have to wait for the computer to respond before sending the data (wouldn't this make the readout much slower?), or will the DRS4 Eval Board keep sending the data to the computer?

                            Reply  Mon Jun 25 14:21:13 2012, Stefan Ritt, triger for measuring time between pulses in channels 

Andrey Kuznetsov wrote:

Stefan Ritt wrote:

On the evaluation board, yes. This board is not optimized for high readout rate. If you do your own electronics, like GBit Ethernet, you could be much faster. 

 What is the readout rate via GBit Ethernet that you have achieved?

Where is the bottleneck in ethernet?

What is the proposed scheme by which the GBit Ethernet will be implemented, will the DRS4 Eval Board have to wait for the computer to respond before sending the data (wouldn't this make the readout much slower?), or will the DRS4 Eval Board keep sending the data to the computer?

With GBit Ethernet you get close to 100 MB/sec, which is the maximal line speed. The protocol to be implemented will achieve that rate. What one usually does is to send events in large blocks upon request from the PC. The trick is to do the request in a clever way, like using a high water mark on the receiving event buffer. So as long as the PC can digest the data quickly enough, the board just keeps sending, which means no overhead.

 

Entry  Mon Jul 9 14:14:48 2012, Ivan Petrov, Problem compiling drs_exam.cpp on windows compile_log.txt

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.

    Reply  Tue Jul 10 13:15:00 2012, Stefan Ritt, Problem compiling drs_exam.cpp on windows 

Ivan Petrov wrote:

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 

       Reply  Wed Jul 11 10:04:51 2012, Ivan Petrov, Problem compiling drs_exam.cpp on windows 

Stefan Ritt wrote:

Ivan Petrov wrote:

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!

Entry  Wed Aug 1 17:42:32 2012, Mayank S. Rajguru, Calculation of loop filter parameters (R,C1and C1) for 1 GHz 

 Hi,

we are planning to use the DRS4 in our board for 1 GHz sampling and digitization.

I have seen in the data sheet that "For the PLL to work, an external loop filter is required. This filter ensures quick locking and stable operation at the desired sampling frequency".

What formula do you use to calculate the values of R, C1 and C2?

Can we use the same given value for different frequencies?

Thanks,

Mayak

    Reply  Mon Aug 6 02:44:00 2012, Stefan Ritt, Calculation of loop filter parameters (R,C1and C1) for 1 GHz 

Mayank S. Rajguru wrote:

 Hi,

we are planning to use the DRS4 in our board for 1 GHz sampling and digitization.

I have seen in the data sheet that "For the PLL to work, an external loop filter is required. This filter ensures quick locking and stable operation at the desired sampling frequency".

What formula do you use to calculate the values of R, C1 and C2?

Can we use the same given value for different frequencies?

Thanks,

Mayak

I never worked out an exact formula for the parameters. It also depends if you want a fast locking time, or a low phase jitter of the PLL. A good starting point are the values from the evaluation board:

R = 130 Ohm

C1 = 4.7 nF

C2 = 1 uF

They should work from 800 MHz to 5 GHz.

- Stefan 

Entry  Tue Aug 28 17:52:45 2012, Zach Miller, DRS-4.0.0 DOScreen.cpp 

Hi,

I found an old thread regarding a fix for DOScreen.cpp for DRS-3.1.0, that fixes an "ambiguous overload problem." Currently when I attempt to build the drs-4.0.0, I get this similar error:

src/DOScreen.cpp:332:39: error: call of overloaded ‘Append(int)’ is ambiguous
 

This section of code is different than what the previous thread was correcting, and though I attempted to apply the logic of the old thread, I haven't fixed this yet.

The following is the code for that section:

-----

329  for (int i=0 ; i<5 ; i++)
330       if (tc & (1<<(i+8))) {
331            if (i < 4)
332              wxst1.Append(wxT('1'+i));
333            else
334              wxst1.Append(wxT('E'));
335           wxst1.Append(wxT('&'));
336        }
337      if (wxst1.Length() > 0)
338         wxst1 = wxst1.Left(wxst1.Length()-1);
339      wxst1.Append(wxT(')'));

------

I've attempted a few fixes, but unfortunately, my understanding of the code is not great, and I haven't managed to fix this yet. Any help would be appreciated.

Thanks,

Zach Miller

    Reply  Wed Aug 29 10:52:44 2012, Stefan Ritt, DRS-4.0.0 DOScreen.cpp 

Zach Miller wrote:

Hi,

I found an old thread regarding a fix for DOScreen.cpp for DRS-3.1.0, that fixes an "ambiguous overload problem." Currently when I attempt to build the drs-4.0.0, I get this similar error:

src/DOScreen.cpp:332:39: error: call of overloaded ‘Append(int)’ is ambiguous
 

This section of code is different than what the previous thread was correcting, and though I attempted to apply the logic of the old thread, I haven't fixed this yet.

The following is the code for that section:

-----

329  for (int i=0 ; i<5 ; i++)
330       if (tc & (1<<(i+8))) {
331            if (i < 4)
332              wxst1.Append(wxT('1'+i));
333            else
334              wxst1.Append(wxT('E'));
335           wxst1.Append(wxT('&'));
336        }
337      if (wxst1.Length() > 0)
338         wxst1 = wxst1.Left(wxst1.Length()-1);
339      wxst1.Append(wxT(')'));

------

I've attempted a few fixes, but unfortunately, my understanding of the code is not great, and I haven't managed to fix this yet. Any help would be appreciated.

Thanks,

Zach Miller

Just put (char) in front of wxT(...), like

   if (tc > 0) {

      wxString wxst1, wxst2;

      wxst1.Append((char)wxT('('));

      for (int i=0 ; i<5 ; i++)

         if (tc & (1<<i)) {

            if (i < 4)

               wxst1.Append((char) (wxT('1'+i)));

            else

               wxst1.Append((char) wxT('E'));

            wxst1.Append((char) wxT('|'));

         }

      for (int i=0 ; i<5 ; i++)

         if (tc & (1<<(i+8))) {

            if (i < 4)

               wxst1.Append((char) (wxT('1'+i)));

            else

               wxst1.Append((char) wxT('E'));

            wxst1.Append((char) wxT('&'));

         }

      if (wxst1.Length() > 0)

         wxst1 = wxst1.Left(wxst1.Length()-1);

      wxst1.Append((char) wxT(')')); 

       Reply  Wed Aug 29 16:42:42 2012, Zach Miller, DRS-4.0.0 DOScreen.cpp 

Stefan Ritt wrote:

Zach Miller wrote:

Hi,

I found an old thread regarding a fix for DOScreen.cpp for DRS-3.1.0, that fixes an "ambiguous overload problem." Currently when I attempt to build the drs-4.0.0, I get this similar error:

src/DOScreen.cpp:332:39: error: call of overloaded ‘Append(int)’ is ambiguous
 

This section of code is different than what the previous thread was correcting, and though I attempted to apply the logic of the old thread, I haven't fixed this yet.

The following is the code for that section:

-----

329  for (int i=0 ; i<5 ; i++)
330       if (tc & (1<<(i+8))) {
331            if (i < 4)
332              wxst1.Append(wxT('1'+i));
333            else
334              wxst1.Append(wxT('E'));
335           wxst1.Append(wxT('&'));
336        }
337      if (wxst1.Length() > 0)
338         wxst1 = wxst1.Left(wxst1.Length()-1);
339      wxst1.Append(wxT(')'));

------

I've attempted a few fixes, but unfortunately, my understanding of the code is not great, and I haven't managed to fix this yet. Any help would be appreciated.

Thanks,

Zach Miller

Just put (char) in front of wxT(...), like

   if (tc > 0) {

      wxString wxst1, wxst2;

      wxst1.Append((char)wxT('('));

      for (int i=0 ; i<5 ; i++)

         if (tc & (1<<i)) {

            if (i < 4)

               wxst1.Append((char) (wxT('1'+i)));

            else

               wxst1.Append((char) wxT('E'));

            wxst1.Append((char) wxT('|'));

         }

      for (int i=0 ; i<5 ; i++)

         if (tc & (1<<(i+8))) {

            if (i < 4)

               wxst1.Append((char) (wxT('1'+i)));

            else

               wxst1.Append((char) wxT('E'));

            wxst1.Append((char) wxT('&'));

         }

      if (wxst1.Length() > 0)

         wxst1 = wxst1.Left(wxst1.Length()-1);

      wxst1.Append((char) wxT(')')); 

 Hi Stefan,

Thanks for the response. I have tried that and it fixes all the lines except the ones that have:

wxst1.Append((char) (wxT('1'+i)));

Those lines still don't compile for me. I've also tried: wxst1.Append((char) (wxT('1'+(char)i))); and wxst1.Append((char) (wxT((char)'1'+i))); as well as a few other combinations of (char) and Append.

I get the same error of: "Call of overloaded "Append(int)" is ambiguous."

Any other help would be greatly appreciated. Thanks!

-Zach

          Reply  Wed Aug 29 16:45:36 2012, Stefan Ritt, DRS-4.0.0 DOScreen.cpp 

Zach Miller wrote:

Stefan Ritt wrote:

Zach Miller wrote:

Hi,

I found an old thread regarding a fix for DOScreen.cpp for DRS-3.1.0, that fixes an "ambiguous overload problem." Currently when I attempt to build the drs-4.0.0, I get this similar error:

src/DOScreen.cpp:332:39: error: call of overloaded ‘Append(int)’ is ambiguous
 

This section of code is different than what the previous thread was correcting, and though I attempted to apply the logic of the old thread, I haven't fixed this yet.

The following is the code for that section:

-----

329  for (int i=0 ; i<5 ; i++)
330       if (tc & (1<<(i+8))) {
331            if (i < 4)
332              wxst1.Append(wxT('1'+i));
333            else
334              wxst1.Append(wxT('E'));
335           wxst1.Append(wxT('&'));
336        }
337      if (wxst1.Length() > 0)
338         wxst1 = wxst1.Left(wxst1.Length()-1);
339      wxst1.Append(wxT(')'));

------

I've attempted a few fixes, but unfortunately, my understanding of the code is not great, and I haven't managed to fix this yet. Any help would be appreciated.

Thanks,

Zach Miller

Just put (char) in front of wxT(...), like

   if (tc > 0) {

      wxString wxst1, wxst2;

      wxst1.Append((char)wxT('('));

      for (int i=0 ; i<5 ; i++)

         if (tc & (1<<i)) {

            if (i < 4)

               wxst1.Append((char) (wxT('1'+i)));

            else

               wxst1.Append((char) wxT('E'));

            wxst1.Append((char) wxT('|'));

         }

      for (int i=0 ; i<5 ; i++)

         if (tc & (1<<(i+8))) {

            if (i < 4)

               wxst1.Append((char) (wxT('1'+i)));

            else

               wxst1.Append((char) wxT('E'));

            wxst1.Append((char) wxT('&'));

         }

      if (wxst1.Length() > 0)

         wxst1 = wxst1.Left(wxst1.Length()-1);

      wxst1.Append((char) wxT(')')); 

 Hi Stefan,

Thanks for the response. I have tried that and it fixes all the lines except the ones that have:

wxst1.Append((char) (wxT('1'+i)));

Those lines still don't compile for me. I've also tried: wxst1.Append((char) (wxT('1'+(char)i))); and wxst1.Append((char) (wxT((char)'1'+i))); as well as a few other combinations of (char) and Append.

I get the same error of: "Call of overloaded "Append(int)" is ambiguous."

Any other help would be greatly appreciated. Thanks!

-Zach

wxst1.Append((char) (wxT((char)('1'+i))));     maybe ??? 

             Reply  Wed Aug 29 16:57:49 2012, Zach Miller, DRS-4.0.0 DOScreen.cpp 

Stefan Ritt wrote:

Zach Miller wrote:

Stefan Ritt wrote:

Zach Miller wrote:

Hi,

I found an old thread regarding a fix for DOScreen.cpp for DRS-3.1.0, that fixes an "ambiguous overload problem." Currently when I attempt to build the drs-4.0.0, I get this similar error:

src/DOScreen.cpp:332:39: error: call of overloaded ‘Append(int)’ is ambiguous
 

This section of code is different than what the previous thread was correcting, and though I attempted to apply the logic of the old thread, I haven't fixed this yet.

The following is the code for that section:

-----

329  for (int i=0 ; i<5 ; i++)
330       if (tc & (1<<(i+8))) {
331            if (i < 4)
332              wxst1.Append(wxT('1'+i));
333            else
334              wxst1.Append(wxT('E'));
335           wxst1.Append(wxT('&'));
336        }
337      if (wxst1.Length() > 0)
338         wxst1 = wxst1.Left(wxst1.Length()-1);
339      wxst1.Append(wxT(')'));

------

I've attempted a few fixes, but unfortunately, my understanding of the code is not great, and I haven't managed to fix this yet. Any help would be appreciated.

Thanks,

Zach Miller

Just put (char) in front of wxT(...), like

   if (tc > 0) {

      wxString wxst1, wxst2;

      wxst1.Append((char)wxT('('));

      for (int i=0 ; i<5 ; i++)

         if (tc & (1<<i)) {

            if (i < 4)

               wxst1.Append((char) (wxT('1'+i)));

            else

               wxst1.Append((char) wxT('E'));

            wxst1.Append((char) wxT('|'));

         }

      for (int i=0 ; i<5 ; i++)

         if (tc & (1<<(i+8))) {

            if (i < 4)

               wxst1.Append((char) (wxT('1'+i)));

            else

               wxst1.Append((char) wxT('E'));

            wxst1.Append((char) wxT('&'));

         }

      if (wxst1.Length() > 0)

         wxst1 = wxst1.Left(wxst1.Length()-1);

      wxst1.Append((char) wxT(')')); 

 Hi Stefan,

Thanks for the response. I have tried that and it fixes all the lines except the ones that have:

wxst1.Append((char) (wxT('1'+i)));

Those lines still don't compile for me. I've also tried: wxst1.Append((char) (wxT('1'+(char)i))); and wxst1.Append((char) (wxT((char)'1'+i))); as well as a few other combinations of (char) and Append.

I get the same error of: "Call of overloaded "Append(int)" is ambiguous."

Any other help would be greatly appreciated. Thanks!

-Zach

wxst1.Append((char) (wxT((char)('1'+i))));     maybe ??? 

 Aha!

wxst1.Append((char) (wxT('1'+i)));

That one actually works as you initially thought, but you my editor was being picky of (char)wxt... instead of (char) (wxt....). For some reason, it has to have the extra set of parentheses around wxt(). Thank You!

Entry  Thu Oct 4 20:50:36 2012, Zach Miller, DRS5 

Hi,

Our group had previously heard that a "DRS-5.0" might be on the horizon and that it may have ethernet capabilities as well as 16-input channels (we heard this when ordering the DRS-4). Is this still in the works and accurate information? If so, is there a rough estimate to the "release date?"

Thanks for your time,

Zach Miller

    Reply  Thu Oct 4 20:59:18 2012, Stefan Ritt, DRS5 

Zach Miller wrote:

Hi,

Our group had previously heard that a "DRS-5.0" might be on the horizon and that it may have ethernet capabilities as well as 16-input channels (we heard this when ordering the DRS-4). Is this still in the works and accurate information? If so, is there a rough estimate to the "release date?"

Thanks for your time,

Zach Miller

You mix up two things: The DRS5 chip is a new device with improved samling speed (10 GSPS) and lower dead time. This chip might come in 2-3 years. The 16-input board you mentioned is a DAQ board based on the DRS4 chip. This board well be operational beginning of 2013 as a prototype. It is not clear however at this point in which way this board will be made available for public. Maybe we will license this to industry. The design is however pretty much defined: 16 channels with gain 0.1-100, 1 GHz Bandwidth, Gigabit Ethernet output, and multi-board capabilities. Trigger on each channel with logical combinations. 80 MSPS continuous sampling (in addition to the DRS4 sampling). Each channel can be biased 0-210 V for SiPMT or APD power. A 19" 3 HE crate will host 16 boards with 256 channels.

/Stefan

       Reply  Thu Oct 4 21:07:27 2012, Zach Miller, DRS5 

Stefan Ritt wrote:

Zach Miller wrote:

Hi,

Our group had previously heard that a "DRS-5.0" might be on the horizon and that it may have ethernet capabilities as well as 16-input channels (we heard this when ordering the DRS-4). Is this still in the works and accurate information? If so, is there a rough estimate to the "release date?"

Thanks for your time,

Zach Miller

You mix up two things: The DRS5 chip is a new device with improved samling speed (10 GSPS) and lower dead time. This chip might come in 2-3 years. The 16-input board you mentioned is a DAQ board based on the DRS4 chip. This board well be operational beginning of 2013 as a prototype. It is not clear however at this point in which way this board will be made available for public. Maybe we will license this to industry. The design is however pretty much defined: 16 channels with gain 0.1-100, 1 GHz Bandwidth, Gigabit Ethernet output, and multi-board capabilities. Trigger on each channel with logical combinations. 80 MSPS continuous sampling (in addition to the DRS4 sampling). Each channel can be biased 0-210 V for SiPMT or APD power. A 19" 3 HE crate will host 16 boards with 256 channels.

/Stefan

 Thanks, Stefan. That was the information we were looking for.

Cheers.

-Zach

Entry  Fri Oct 12 14:06:04 2012, Moritz von Witzleben, DRS abbreviation 

Hello,

what is the abbreviation of DRS?

Thanks and kind Regards,

Moritz

    Reply  Fri Oct 12 14:09:37 2012, Stefan Ritt, DRS abbreviation 

Moritz von Witzleben wrote:

Hello,

what is the abbreviation of DRS?

Thanks and kind Regards,

Moritz

Domino Ring Sampler. 

Entry  Thu Nov 1 20:08:33 2012, hongwei yang, DRS4 firmware 

Hi,

    We are using drs4 board, but oscilloscope app will somehow stop to work if we config trigger into "or and", When I look into the drs4 firmware file drs4_eval3_app.vhd, I couldn't find the trigger_config value assignment which is mentioned at(#7 offset 0x1E from 31 downto 16) in manual_version 4.

could you help me find this trigger_config access point? Or is there any drs4_eval4_app.vhd missing in the source files?

 

thanks

 

Hongwei

    Reply  Thu Nov 1 20:17:42 2012, Stefan Ritt, DRS4 firmware drs4_eval4_app.vhd

hongwei yang wrote:

Hi,

    We are using drs4 board, but oscilloscope app will somehow stop to work if we config trigger into "or and", When I look into the drs4 firmware file drs4_eval3_app.vhd, I couldn't find the trigger_config value assignment which is mentioned at(#7 offset 0x1E from 31 downto 16) in manual_version 4.

could you help me find this trigger_config access point?

 

thanks

 

Hongwei

The "and" in the trigger section means now "coincidence". So the V4 board can trigger on a coincidence between two or more channels. If there is no pulse at the same time on the coincidence channels, the board will of course not trigger. The according firmware was introduced in V4, so please look at drs4_eval4_app.vhd (not eval3).

I just realized that the V4 firmware might be missing in the distribution, so I have attached it here. Look for drs_ctl_trigger_config.

 

Best regards,

Stefan

       Reply  Thu Nov 1 20:21:44 2012, hongwei yang, DRS4 firmware 

Stefan Ritt wrote:

hongwei yang wrote:

Hi,

    We are using drs4 board, but oscilloscope app will somehow stop to work if we config trigger into "or and", When I look into the drs4 firmware file drs4_eval3_app.vhd, I couldn't find the trigger_config value assignment which is mentioned at(#7 offset 0x1E from 31 downto 16) in manual_version 4.

could you help me find this trigger_config access point?

 

thanks

 

Hongwei

The "and" in the trigger section means now "coincidence". So the V4 board can trigger on a coincidence between two or more channels. If there is no pulse at the same time on the coincidence channels, the board will of course not trigger. The according firmware was introduced in V4, so please look at drs4_eval4_app.vhd (not eval3).

I just realized that the V4 firmware might be missing in the distribution, so I have attached it here. Look for drs_ctl_trigger_config.

 

Best regards,

Stefan

 Ah, great, that helps, Thank you!

 

Hongwei

          Reply  Thu Nov 1 20:25:53 2012, hongwei yang, DRS4 firmware 

hongwei yang wrote:

Stefan Ritt wrote:

hongwei yang wrote:

Hi,

    We are using drs4 board, but oscilloscope app will somehow stop to work if we config trigger into "or and", When I look into the drs4 firmware file drs4_eval3_app.vhd, I couldn't find the trigger_config value assignment which is mentioned at(#7 offset 0x1E from 31 downto 16) in manual_version 4.

could you help me find this trigger_config access point?

 

thanks

 

Hongwei

The "and" in the trigger section means now "coincidence". So the V4 board can trigger on a coincidence between two or more channels. If there is no pulse at the same time on the coincidence channels, the board will of course not trigger. The according firmware was introduced in V4, so please look at drs4_eval4_app.vhd (not eval3).

I just realized that the V4 firmware might be missing in the distribution, so I have attached it here. Look for drs_ctl_trigger_config.

 

Best regards,

Stefan

 Ah, great, that helps, Thank you!

 

Hongwei

 By the way, will there be a drs4_eval4.vhd as well?

             Reply  Thu Nov 1 20:32:03 2012, Stefan Ritt, DRS4 firmware drs4_eval4.vhd

hongwei yang wrote:

hongwei yang wrote:

Stefan Ritt wrote:

hongwei yang wrote:

Hi,

    We are using drs4 board, but oscilloscope app will somehow stop to work if we config trigger into "or and", When I look into the drs4 firmware file drs4_eval3_app.vhd, I couldn't find the trigger_config value assignment which is mentioned at(#7 offset 0x1E from 31 downto 16) in manual_version 4.

could you help me find this trigger_config access point?

 

thanks

 

Hongwei

The "and" in the trigger section means now "coincidence". So the V4 board can trigger on a coincidence between two or more channels. If there is no pulse at the same time on the coincidence channels, the board will of course not trigger. The according firmware was introduced in V4, so please look at drs4_eval4_app.vhd (not eval3).

I just realized that the V4 firmware might be missing in the distribution, so I have attached it here. Look for drs_ctl_trigger_config.

 

Best regards,

Stefan

 Ah, great, that helps, Thank you!

 

Hongwei

 By the way, will there be a drs4_eval4.vhd as well?

 Here it is.

                Reply  Thu Nov 1 20:46:53 2012, hongwei yang, DRS4 firmware 

Stefan Ritt wrote:

hongwei yang wrote:

hongwei yang wrote:

Stefan Ritt wrote:

hongwei yang wrote:

Hi,

    We are using drs4 board, but oscilloscope app will somehow stop to work if we config trigger into "or and", When I look into the drs4 firmware file drs4_eval3_app.vhd, I couldn't find the trigger_config value assignment which is mentioned at(#7 offset 0x1E from 31 downto 16) in manual_version 4.

could you help me find this trigger_config access point?

 

thanks

 

Hongwei

The "and" in the trigger section means now "coincidence". So the V4 board can trigger on a coincidence between two or more channels. If there is no pulse at the same time on the coincidence channels, the board will of course not trigger. The according firmware was introduced in V4, so please look at drs4_eval4_app.vhd (not eval3).

I just realized that the V4 firmware might be missing in the distribution, so I have attached it here. Look for drs_ctl_trigger_config.

 

Best regards,

Stefan

 Ah, great, that helps, Thank you!

 

Hongwei

 By the way, will there be a drs4_eval4.vhd as well?

 Here it is.

 Thanks. have a good day

Entry  Mon Oct 29 18:30:28 2012, Martin Petriska, GetWave 

 I have some question according to GetWave function. In drs_exam.cpp simple GetWave(0,0,wave_array[]) etc...is used. Is there primary (cell) calibration, secondary calibration (Readout) and remove Spikes used, as in DRS Oscilloscope application?

    Reply  Tue Nov 13 11:26:32 2012, Stefan Ritt, GetWave 

Martin Petriska wrote:

 I have some question according to GetWave function. In drs_exam.cpp simple GetWave(0,0,wave_array[]) etc...is used. Is there primary (cell) calibration, secondary calibration (Readout) and remove Spikes used, as in DRS Oscilloscope application?

 Yes, yes, no. To get spike removals, you need the function RemoveSpikes from Osci.cpp in the DRSOsc project.

Entry  Wed Nov 21 08:34:52 2012, Gyuhee Kim, Question for using Multi board 

 Hi.

 

I have 2 DRS4 evaluation V4 boards, and I want to use these 2 board to multi board DAQ system for 4 ch vs 4 ch DAQ.

But there is no option for multi board use. I just only find the multi board trigger mode check button on DRS4 Oscilloscope program, but I couldn`t check. 

Is there any method to use multi board?

 

Best regards.

Gyuhee.

    Reply  Wed Nov 21 08:38:26 2012, Stefan Ritt, Question for using Multi board 

Gyuhee Kim wrote:

 Hi.

 

I have 2 DRS4 evaluation V4 boards, and I want to use these 2 board to multi board DAQ system for 4 ch vs 4 ch DAQ.

But there is no option for multi board use. I just only find the multi board trigger mode check button on DRS4 Oscilloscope program, but I couldn`t check. 

Is there any method to use multi board?

 

Best regards.

Gyuhee.

This mode is not yet implemented in firmware. Maybe I find some time towards the end of this year to add this. At the moment, you have to build and external trigger to synchronize the two boards. There are also 16-channel boards on the market where you would not need a multi-board mode. Just Google for "DT5742".

/Stefan

       Reply  Wed Nov 21 08:48:00 2012, Gyuhee Kim, Question for using Multi board 

Stefan Ritt wrote:

Gyuhee Kim wrote:

 Hi.

 

I have 2 DRS4 evaluation V4 boards, and I want to use these 2 board to multi board DAQ system for 4 ch vs 4 ch DAQ.

But there is no option for multi board use. I just only find the multi board trigger mode check button on DRS4 Oscilloscope program, but I couldn`t check. 

Is there any method to use multi board?

 

Best regards.

Gyuhee.

This mode is not yet implemented in firmware. Maybe I find some time towards the end of this year to add this. At the moment, you have to build and external trigger to synchronize the two boards. There are also 16-channel boards on the market where you would not need a multi-board mode. Just Google for "DT5742".

/Stefan

 Thanks Stefan.

I will build external trigger system. 

Entry  Wed Nov 28 16:54:46 2012, Stefan Ritt, DRS Oscilloscope for Raspberry Pi and Mac OSX 10.8 screenshot_pi.png

I made a pre-compiled package for Mac OSX 10.8 (Mountain Lion), so one should be able to install the DRS Oscilloscope software with one mouse click on a recent Mac.

The Makefile in the tar ball now also supports OSX 10.8, so one could even compile it from the sources on a Mac, after libusb-1.0 and wxWidgets have been installed. That might then also work on older versions of OSX.

In addition, the software has been adaptes so that it compiles nicely on a Raspberry Pi (http://www.raspberrypi.org), a screenshot has been attached. Together with a Raspberry Pi and an old screen, the evaluation board is one of the cheapest available oscilloscopes.

 

 

Entry  Mon Dec 3 08:32:28 2012, Gyuhee Kim, Another question about using multi boards. 

 Hi.

 

I asked about using multi boards some days ago, and I got answer to use external trigger. (Thanks Stefan!)

And here is another question. I made two external triggers and try to acquire coincidence data using two boards. but DRS Oscilloscope program can connect only one board and don`t acquire both of them simultaneously.

So I tried to use two computer for each board separately, but, well, you already know, I failed to acquire because two computers don`t promise to synchronize the two boards acquisition.

Is there any method to solve this problem?

 

1. I want to acquire coincidence data from the two DRS 4 Evaluation board V4 simultaneosly.

2. I have external trigger to provide the two boards at the same time.

3. How can I get data from the two boards?

 

Best regards.

Gyuhee.

    Reply  Mon Dec 3 09:18:09 2012, Stefan Ritt, Another question about using multi boards. 

Gyuhee Kim wrote:

 Hi.

 

I asked about using multi boards some days ago, and I got answer to use external trigger. (Thanks Stefan!)

And here is another question. I made two external triggers and try to acquire coincidence data using two boards. but DRS Oscilloscope program can connect only one board and don`t acquire both of them simultaneously.

So I tried to use two computer for each board separately, but, well, you already know, I failed to acquire because two computers don`t promise to synchronize the two boards acquisition.

Is there any method to solve this problem?

 

1. I want to acquire coincidence data from the two DRS 4 Evaluation board V4 simultaneosly.

2. I have external trigger to provide the two boards at the same time.

3. How can I get data from the two boards?

 

Best regards.

Gyuhee.

You have to write your own program. DRS Oscilloscope does not (yet) support this. Take drs_exam.cpp as a starting point and try to extend it to two boards. One tricky point is that the external trigger may only fire AFTER the two boards have been read out. So you need some means of re-enabling the external trigger after you read out both boards.

Stefan 

       Reply  Mon Dec 3 11:40:35 2012, Gyuhee Kim, Another question about using multi boards. 

Stefan Ritt wrote:

Gyuhee Kim wrote:

 Hi.

 

I asked about using multi boards some days ago, and I got answer to use external trigger. (Thanks Stefan!)

And here is another question. I made two external triggers and try to acquire coincidence data using two boards. but DRS Oscilloscope program can connect only one board and don`t acquire both of them simultaneously.

So I tried to use two computer for each board separately, but, well, you already know, I failed to acquire because two computers don`t promise to synchronize the two boards acquisition.

Is there any method to solve this problem?

 

1. I want to acquire coincidence data from the two DRS 4 Evaluation board V4 simultaneosly.

2. I have external trigger to provide the two boards at the same time.

3. How can I get data from the two boards?

 

Best regards.

Gyuhee.

You have to write your own program. DRS Oscilloscope does not (yet) support this. Take drs_exam.cpp as a starting point and try to extend it to two boards. One tricky point is that the external trigger may only fire AFTER the two boards have been read out. So you need some means of re-enabling the external trigger after you read out both boards.

Stefan 

That`s very bad news for me. I don`t have much time to study & write C programming...

Anyway, Thank you very much Stefan.

 

Best regards.

Gyuhee.

Entry  Tue Dec 4 09:24:22 2012, Zhongwei Du, Question of drs4 using 

When Denable and Dwrite is high , the voltage of PLLOUT is 0 V.  And  the Dtap is turn high with no delay when the Denable turns high.

After power up and configuration(the WSR,WCR,CR are all set to 11111111), the readout data is no change whenever the input analog signal and rofs,bias,oofs changes. I have test useing the DAC to supply the Dspeed voltage, and change a new DRS4 chip, but all is the same. The readout data is strange : the first about 100 cells is rise or fall  and the last 900 cells is out of the range of ADC.

So how should I do for debugging the drs4 now.

    Reply  Tue Dec 4 09:39:44 2012, Stefan Ritt, Question of drs4 using 

Zhongwei Du wrote:

When Denable and Dwrite is high , the voltage of PLLOUT is 0 V.  And  the Dtap is turn high with no delay when the Denable turns high.

After power up and configuration(the WSR,WCR,CR are all set to 11111111), the readout data is no change whenever the input analog signal and rofs,bias,oofs changes. I have test useing the DAC to supply the Dspeed voltage, and change a new DRS4 chip, but all is the same. The readout data is strange : the first about 100 cells is rise or fall  and the last 900 cells is out of the range of ADC.

So how should I do for debugging the drs4 now.

The first thing to make work is to have DTAP oscillating with fsamp/2048. Keep Denable and Dwrite low (required during power-on, see elog:10), set Dspeed to 2.5V, then rise Denable and Dwrite. You should see Dtap toggling at about 2.4 MHz. If not, double check all supply voltages, and especially all soldering points. The QFN package is a bit hard to solder.

/Stefan 

       Reply  Tue Dec 4 09:50:11 2012, Zhongwei Du, Question of drs4 using 

Stefan Ritt wrote:

Zhongwei Du wrote:

When Denable and Dwrite is high , the voltage of PLLOUT is 0 V.  And  the Dtap is turn high with no delay when the Denable turns high.

After power up and configuration(the WSR,WCR,CR are all set to 11111111), the readout data is no change whenever the input analog signal and rofs,bias,oofs changes. I have test useing the DAC to supply the Dspeed voltage, and change a new DRS4 chip, but all is the same. The readout data is strange : the first about 100 cells is rise or fall  and the last 900 cells is out of the range of ADC.

So how should I do for debugging the drs4 now.

The first thing to make work is to have DTAP oscillating with fsamp/2048. Keep Denable and Dwrite low (required during power-on, see elog:10), set Dspeed to 2.5V, then rise Denable and Dwrite. You should see Dtap toggling at about 2.4 MHz. If not, double check all supply voltages, and especially all soldering points. The QFN package is a bit hard to solder.

/Stefan 

 "Keep Denable and Dwrite low (required during power-on, see elog:10), set Dspeed to 2.5V, then rise Denable and Dwrite. You should see Dtap toggling at about 2.4 MHz. "

In this process ,  should i config any registers( WSR,WCR,CR  ) ?

          Reply  Tue Dec 4 09:55:43 2012, Stefan Ritt, Question of drs4 using 

Zhongwei Du wrote:

Stefan Ritt wrote:

Zhongwei Du wrote:

When Denable and Dwrite is high , the voltage of PLLOUT is 0 V.  And  the Dtap is turn high with no delay when the Denable turns high.

After power up and configuration(the WSR,WCR,CR are all set to 11111111), the readout data is no change whenever the input analog signal and rofs,bias,oofs changes. I have test useing the DAC to supply the Dspeed voltage, and change a new DRS4 chip, but all is the same. The readout data is strange : the first about 100 cells is rise or fall  and the last 900 cells is out of the range of ADC.

So how should I do for debugging the drs4 now.

The first thing to make work is to have DTAP oscillating with fsamp/2048. Keep Denable and Dwrite low (required during power-on, see elog:10), set Dspeed to 2.5V, then rise Denable and Dwrite. You should see Dtap toggling at about 2.4 MHz. If not, double check all supply voltages, and especially all soldering points. The QFN package is a bit hard to solder.

/Stefan 

 "Keep Denable and Dwrite low (required during power-on, see elog:10), set Dspeed to 2.5V, then rise Denable and Dwrite. You should see Dtap toggling at about 2.4 MHz. "

In this process ,  should i config any registers( WSR,WCR,CR  ) ?

After power-up reset, these registers are all set to "1", which should be ok to start.

BTW, Jinhong Wang <wangjinh@mail.ustc.edu.cn> from your institute hast the chip correctly working. Maybe he can help you in a more direct way than I can.

  

Entry  Thu Dec 13 12:03:29 2012, Evgeni, DRS-4 trigger 

How to configure DRS oscilloscope for the oscillations with an amplitude greater than the value of the exposed
in the trigger (internal). 

    Reply  Thu Dec 13 12:14:35 2012, Stefan Ritt, DRS-4 trigger 

Evgeni wrote:

How to configure DRS oscilloscope for the oscillations with an amplitude greater than the value of the exposed
in the trigger (internal). 

Sorry, I don't understand that question. The DRS4 Evaluation board input signal range is 1V. If you have larger signals, you have to attenuante them externally.

/Stefan 

       Reply  Thu Dec 13 19:49:47 2012, Evgeni, DRS-4 trigger 

 

Stefan Ritt wrote:

 

Evgeni wrote:

How to configure DRS oscilloscope for the oscillations with an amplitude greater than the value of the exposed
in the trigger (internal). 

 

Sorry, I don't understand that question. The DRS4 Evaluation board input signal range is 1V. If you have larger signals, you have to attenuante them externally.

/Stefan 

 

 

Can I adjust the internal trigger DRS oscilloscope for signal extraction 0.5 volts (for example) from any of the four channels. In our case, there is a lot of noise with low amplitude, which must be removed during the registration. We need to record the individual pulses of higher amplitude than the noise. So we want to use the internal trigger DRS oscilloscope to cut this noise by setting up its threshold amplitude noise.

          Reply  Fri Dec 14 08:42:53 2012, Stefan Ritt, DRS-4 trigger DRSOsc.png

Evgeni wrote:

 

Stefan Ritt wrote:

 

Evgeni wrote:

How to configure DRS oscilloscope for the oscillations with an amplitude greater than the value of the exposed
in the trigger (internal). 

 

Sorry, I don't understand that question. The DRS4 Evaluation board input signal range is 1V. If you have larger signals, you have to attenuante them externally.

/Stefan 

 

 

Can I adjust the internal trigger DRS oscilloscope for signal extraction 0.5 volts (for example) from any of the four channels. In our case, there is a lot of noise with low amplitude, which must be removed during the registration. We need to record the individual pulses of higher amplitude than the noise. So we want to use the internal trigger DRS oscilloscope to cut this noise by setting up its threshold amplitude noise.

 

 Sure, you can set the trigger level with the vertical slider (see attached figure). The trigger level works form -0.5V to +0.5V. Just like with a normal oscilloscope. I thought this would be obvious...

             Reply  Fri Dec 14 10:07:54 2012, Evgeni, DRS-4 trigger 

 

Stefan Ritt wrote:

 

Evgeni wrote:

 

Stefan Ritt wrote:

 

Evgeni wrote:

How to configure DRS oscilloscope for the oscillations with an amplitude greater than the value of the exposed
in the trigger (internal). 

 

Sorry, I don't understand that question. The DRS4 Evaluation board input signal range is 1V. If you have larger signals, you have to attenuante them externally.

/Stefan 

 

 

Can I adjust the internal trigger DRS oscilloscope for signal extraction 0.5 volts (for example) from any of the four channels. In our case, there is a lot of noise with low amplitude, which must be removed during the registration. We need to record the individual pulses of higher amplitude than the noise. So we want to use the internal trigger DRS oscilloscope to cut this noise by setting up its threshold amplitude noise.

 

 

 Sure, you can set the trigger level with the vertical slider (see attached figure). The trigger level works form -0.5V to +0.5V. Just like with a normal oscilloscope. I thought this would be obvious...

 

    That's it? Thank you for your comprehensive answer.

    Reply  Fri Dec 14 10:07:14 2012, Evgeni, DRS-4 trigger 

 

Evgeni wrote:

How to configure DRS oscilloscope for the oscillations with an amplitude greater than the value of the exposed
in the trigger (internal). 

 

 

Entry  Thu Dec 6 09:23:36 2012, Martin Petriska, EVM rev4 board trigger change and drs_example 

 I switched from rev 3 to rev 4 board, but have some problems with triggering, board is now waiting for trigger (rev.3 is working). How to do in drs_exam.cpp for example triggering on Ch0 && CH1 ?

Software 4.0.0, windows version.

Here is old trigger initialisation: 

b->EnableTrigger(0,1);

b->SetTriggerSource(0);

b->SetTriggerLevel(0.25, false);

b->SetTriggerDelayNs(0);

 

Btw. Is it possible to set up different trigger Levels for each channel ?

 

(If there is some interest here is my code in Qt, still aplha) http://sourceforge.net/p/qtpals/code

    Reply  Fri Dec 14 21:49:29 2012, Stefan Ritt, EVM rev4 board trigger change and drs_example 

Martin Petriska wrote:

 I switched from rev 3 to rev 4 board, but have some problems with triggering, board is now waiting for trigger (rev.3 is working). How to do in drs_exam.cpp for example triggering on Ch0 && CH1 ?

Software 4.0.0, windows version.

Here is old trigger initialisation: 

b->EnableTrigger(0,1);

b->SetTriggerSource(0);

b->SetTriggerLevel(0.25, false);

b->SetTriggerDelayNs(0);

 

Btw. Is it possible to set up different trigger Levels for each channel ?

 

(If there is some interest here is my code in Qt, still aplha) http://sourceforge.net/p/qtpals/code

Sorry the late reply.

In V4, triggering has changed. You can trigger now on an OR or AND of channels. Therefore you have to supply a bitmask, where the 1st bit = CH1, 2nd bit = CH2 and so on. Have a look at the most recent drs_exam. It contains code:

 

   /* use following lines to enable hardware trigger on CH1 at 50 mV positive edge */
   if (b->GetBoardType() == 8) {     // Evaluaiton Board V4 
      b->EnableTrigger(1, 0);           // enable hardware trigger
      b->SetTriggerSource(1<<0);        // set CH1 as source
   } else {                          // Evaluation Board V3
      b->EnableTrigger(0, 1);           // lemo off, analog trigger on
      b->SetTriggerSource(0);           // use CH1 as source
   } 

So if you want CH1 && CH2, you look at the source code of SetTriggerSource. It contains

 

      // Set trigger configuration
   // OR  0=CH1, 1=CH2, 2=CH3, 3=CH4, 4=EXT
   // AND 8=CH1, 9=CH2, 10=CH3, 11=CH4, 12=EXT

 

So an AND between CH1 and CH2 needs a

    b->SetTriggerSource(1<<8 | 1<<9);

Your code looks interesting. Do you have a screenshot or can you explain what it does? 

Entry  Thu Dec 27 00:12:12 2012, Jinhong Wang, variation of sampling capacitors 

Hi Stefan,

A quick question, what is the typical variation of the sampling capacitors in DRS4?  Will this variation be significant to affect your sampling result?

 Best,

Jinhong

    Reply  Thu Dec 27 09:49:17 2012, Stefan Ritt, variation of sampling capacitors 

Jinhong Wang wrote:

Hi Stefan,

A quick question, what is the typical variation of the sampling capacitors in DRS4?  Will this variation be significant to affect your sampling result?

 Best,

Jinhong 

The capacitors sample the input voltage, not the charge, so the actual size of the capacitors does not matter on first order (the variations might be in the order of 5%). A bigger effect is the variation of the analog switches in the front of the capacitors, which is about 15%. So the actual bandwidth each cell sees varies by maybe 20% (given by the R and the C), but this comes only into play when sampling steep edges.

Stefan

       Reply  Thu Dec 27 18:15:14 2012, Jinhong Wang, variation of sampling capacitors 

Stefan Ritt wrote:

Jinhong Wang wrote:

Hi Stefan,

A quick question, what is the typical variation of the sampling capacitors in DRS4?  Will this variation be significant to affect your sampling result?

 Best,

Jinhong 

The capacitors sample the input voltage, not the charge, so the actual size of the capacitors does not matter on first order (the variations might be in the order of 5%). A bigger effect is the variation of the analog switches in the front of the capacitors, which is about 15%. So the actual bandwidth each cell sees varies by maybe 20% (given by the R and the C), but this comes only into play when sampling steep edges.

Stefan

 Great to know this! Thanks~

Jinhong

          Reply  Fri Feb 1 17:43:48 2013, Jinhong Wang, variation of sampling capacitors 

Jinhong Wang wrote:

Stefan Ritt wrote:

Jinhong Wang wrote:

Hi Stefan,

A quick question, what is the typical variation of the sampling capacitors in DRS4?  Will this variation be significant to affect your sampling result?

 Best,

Jinhong 

The capacitors sample the input voltage, not the charge, so the actual size of the capacitors does not matter on first order (the variations might be in the order of 5%). A bigger effect is the variation of the analog switches in the front of the capacitors, which is about 15%. So the actual bandwidth each cell sees varies by maybe 20% (given by the R and the C), but this comes only into play when sampling steep edges.

Stefan

 Great to know this! Thanks~

Jinhong

 Hi Dr. Stefan,

So the sampling capacitors store the input voltage instead of the charge. What about the readout circuits? I saw there is a buffer followed each sampling capacitor. Do you buffer the charge (like a charge sensitive amplifier)  or the voltage? From Fig.12, 14 in datasheet, it seems most probably the readout is a charging or discharging of a capacitor. Could you please add some comments on this? 

Cheers,

Jinhong

             Reply  Tue Feb 5 14:38:35 2013, Stefan Ritt, variation of sampling capacitors 

Jinhong Wang wrote:

Hi Dr. Stefan,

So the sampling capacitors store the input voltage instead of the charge. What about the readout circuits? I saw there is a buffer followed each sampling capacitor. Do you buffer the charge (like a charge sensitive amplifier)  or the voltage? From Fig.12, 14 in datasheet, it seems most probably the readout is a charging or discharging of a capacitor. Could you please add some comments on this? 

Cheers,

Jinhong

The buffer buffers the voltage, not the charge. The curves in Fig. 12, 14 indicate that the voltage followers take some time until they settle. 

Stefan

Entry  Wed Feb 13 16:58:40 2013, Martin Petriska, Nonuniform sampling 

 Are there any plans to include reconstruction of nonuniform sampling  in DRS4 to get uniformly sampled data?

Im now reading article IEEE Trans on Circ. ans Systems I, Vol.55 No.8 sept. 2008 Reconstruction of Nonuniformly Sampled Bandlimited Signals Usinga Differentiator–Multiplier Cascade by Stefan Tertinek and Christian Vogel

and plan to implement it, but may be somebody has it done before me.

 

    Reply  Wed Feb 13 17:03:53 2013, Stefan Ritt, Nonuniform sampling 

Martin Petriska wrote:

 Are there any plans to include reconstruction of nonuniform sampling  in DRS4 to get uniformly sampled data?

Im now reading article IEEE Trans on Circ. ans Systems I, Vol.55 No.8 sept. 2008 Reconstruction of Nonuniformly Sampled Bandlimited Signals Usinga Differentiator–Multiplier Cascade by Stefan Tertinek and Christian Vogel

and plan to implement it, but may be somebody has it done before me.

 

Interesting paper. I was not aware of this method. Sounds interesting. AFAIK, nobody has implemented it so far.

My (old) plan was to linearly interpolate samples (something you could do in an FPGA as well), but this will introduce (small) errors. The next best thing would be to do some spline interpolation, but this is time consuming and not suited for an FPGA.

If you get good results with the method above, please let others know about it.

/Stefan 

Entry  Fri Feb 22 11:46:17 2013, Yury Golod, DRS4 trigger, different polarity 

I need to synchronize two signals. These signals have a different polarity.

I can set triggers on different levels. But I can't set different polarity of triggers.

Now I can set (T1 and T2), I need to set (T1 and (not T2))

Is it possible?

 

           

d->SetTriggerLevel(-0.4,0.4,0.0,0.0,false);

d->EnableTrigger(1, 0);  // Enable trigger

d->SetTriggerSource(1<<8 | 1<<9);  // T1 and T2

 

file DRS.cpp:

int DRSBoard::SetTriggerLevel(double voltage1,double voltage2, double voltage3,double voltage4,bool negative)

{

      SetDAC(fDAC_TLEVEL1, voltage1/2 + 0.8);

      SetDAC(fDAC_TLEVEL2, voltage2/2 + 0.8);

 

    Reply  Fri Feb 22 11:56:57 2013, Stefan Ritt, DRS4 trigger, different polarity 

Yury Golod wrote:

I need to synchronize two signals. These signals have a different polarity.

I can set triggers on different levels. But I can't set different polarity of triggers.

Now I can set (T1 and T2), I need to set (T1 and (not T2))

Is it possible?

 

           

 

d->SetTriggerLevel(-0.4,0.4,0.0,0.0,false);

d->EnableTrigger(1, 0);  // Enable trigger

d->SetTriggerSource(1<<8 | 1<<9);  // T1 and T2

 

file DRS.cpp:

int DRSBoard::SetTriggerLevel(double voltage1,double voltage2, double voltage3,double voltage4,bool negative)

{

      SetDAC(fDAC_TLEVEL1, voltage1/2 + 0.8);

      SetDAC(fDAC_TLEVEL2, voltage2/2 + 0.8);

 

There is no way to select different polarities, it is not implemented in the firmware. Like your digital oscilloscope has also only one polarity switch.

The only way to do it is to use a (passive) inverter, so that you have two signals of the same polarity. Something like this:

http://www.phillipsscientific.com/pdf/460ds.pdf

 

Entry  Thu Feb 28 10:47:14 2013, Dmitry Hits, clock and trigger outs 
Hi,
I am considering using the DRS4 evaluation board as an ADC card for the wire chamber in the physics lab (VP) experiment at ETH. However, the wire 
chamber has 8 outputs, so I would need to have two of such boards. Is it possible to synchronise them, online or offline? From the website, it looks 
like yes, but the documentation says that these features (trigger and clock out) may not have been implemented in firmware yet. Could you tell me 
the status?

Thank you very much,

Dmitry.
    Reply  Thu Feb 28 12:58:44 2013, Stefan Ritt, clock and trigger outs 
> Hi,
> I am considering using the DRS4 evaluation board as an ADC card for the wire chamber in the physics lab (VP) experiment at ETH. However, the wire 
> chamber has 8 outputs, so I would need to have two of such boards. Is it possible to synchronise them, online or offline? From the website, it looks 
> like yes, but the documentation says that these features (trigger and clock out) may not have been implemented in firmware yet. Could you tell me 
> the status?
> 
> Thank you very much,
> 
> Dmitry.

I'm right now working on it. If you only need 2-3 ns accuracy  between the two boards then you can do this already now without firmware upgrade. The software for this is in principle ready, but I have to 
finish the documentation. Since I'm on a business travel right now this might take me some time (weeks?). 

If you want better timing (O(100ps)) between the boards, then you will need a firmware update. Or you wait until we ship boards with the new firmware. I will announce this through this forum.

Stefan
Entry  Wed Feb 27 13:47:32 2013, Georg Winner, Chip Test - Cell Error 

When starting Chip Test in DRS Command Line Interface, I receive the following message:

Cell error on channel 1, cell 5: -154.4 mV instead 0 mV

Chip Error!

What does this mean? The maximal peak-to-peak Amplitude given to channel was for a short time 10V.

The graphical interface shows no artefacts when using channel 1.

 

    Reply  Wed Mar 6 13:08:03 2013, Stefan Ritt, Chip Test - Cell Error 

Georg Winner wrote:

When starting Chip Test in DRS Command Line Interface, I receive the following message:

Cell error on channel 1, cell 5: -154.4 mV instead 0 mV

Chip Error!

What does this mean? The maximal peak-to-peak Amplitude given to channel was for a short time 10V.

The graphical interface shows no artefacts when using channel 1.

 

The "Chip Test" command is made for a special test board we use for chip testing. This command will not work with the evaluation board, since only four of the 8 DRS channels are connected there. So just ignore it and verify the board functionality by looking at the graphical interface.

/Stefan 

Entry  Mon Mar 25 11:12:53 2013, Georg Winner, Differences in Source Code 

I have noticed some differences in the source code between Windows (4.0.0) and Linux (4.0.1) Version.

drs_exam.cpp: In the windows version when setting the trigger there is no part "if (b->GetBoardType() == 8) {...} else {...}" like in Linux version. So under Windows drs_exam does not start readout of DRS 4 Evalutation Board V4, because it does not get the trigger, under linux the board can be read out succesfull. I have found out, that adding the missing part solves the problem for the windows version.

drs.cpp (Windows Version), line 2101, function "int DRSBoard::SetTriggerDelayNs(int delay)":

There is no operation which  calculates the variable "fTriggerDelayNs" out of variable "ticks" like in function "int DRSBoard::SetTriggerDelayPercent(int delay)" (Line 2073). So "fTriggerDelayNs" can get diverse values when using one of the Trigger Setting Functions. Was this intended?

 

    Reply  Thu Apr 4 11:21:04 2013, Stefan Ritt, Differences in Source Code 

Georg Winner wrote:

I have noticed some differences in the source code between Windows (4.0.0) and Linux (4.0.1) Version.

drs_exam.cpp: In the windows version when setting the trigger there is no part "if (b->GetBoardType() == 8) {...} else {...}" like in Linux version. So under Windows drs_exam does not start readout of DRS 4 Evalutation Board V4, because it does not get the trigger, under linux the board can be read out succesfull. I have found out, that adding the missing part solves the problem for the windows version.

drs.cpp (Windows Version), line 2101, function "int DRSBoard::SetTriggerDelayNs(int delay)":

There is no operation which  calculates the variable "fTriggerDelayNs" out of variable "ticks" like in function "int DRSBoard::SetTriggerDelayPercent(int delay)" (Line 2073). So "fTriggerDelayNs" can get diverse values when using one of the Trigger Setting Functions. Was this intended?

 

Thanks for reporting the problem in drs_exam.cpp. The windows and linux versions sometimes differ a bit. I'm working right now on a complete new version, wich will bring both together again.

Concerning fTriggerDelayNs and ticks, they are correlated. One tick is a single delay unit in the FPGA. On the newest boards the unit is 4.8ns long. So

ticks = fTriggerDelayNs / 4.8

fTriggerDelayNs = ticks * 4.8

fTriggerDelayNs gets set at the first line of SetTriggerDelayNs:

int DRSBoard::SetTriggerDelayNs(int delay)
/* set trigger delay in nanoseconds */
{
   short ticks, reg;
   fTriggerDelayNs = delay;

So I cannot see how fTriggerDelayNS should get diverse values?

 

Entry  Mon Apr 8 18:11:02 2013, Dmitry Hits, binary to root 

 Hi,

 

Does anyone has a program that converts a binary file from drsosc  output to a ROOT tree format?

 

Thank you,

 

Dmitry.

Entry  Thu Apr 11 22:41:13 2013, Bill Ashmanskas, code/details for optimal DRS4 timing calibration? tcalib.png

Hi Stefan,

Is either some example code or a detailed written description available for the improved DRS4 timing-calibration algorithm described by Daniel Stricker-Shaver at MIC 2012?  I think you told me that you had verified the results with your own test set-up, so I figure there must be at least two sets of code in existence to implement this calibration.  (I have Daniel's presentation slides.)

I managed to find a ping-pong distribution of cell widths that looks quite similar to that shown in Daniel's slides, using an algorithm similar to the technique one uses to find radial offsets in a tracking chamber (i.e. using residuals weighted by track slope), but I'd rather use the method with which you and Daniel have already found good results.  (The attached graph shows in black the histogram of cell widths for essentially the algorithm used in DRS.cpp/DRSBoard::AnalyzeWF, and in blue the histogram of cell widths extracted from the slope-weighted residuals for a periodic reference signal.)

By the way, since Daniel finds a FWHM coincidence-timing resolution around 20-25ps at 5 GSPS (for perfectly identical pulses), should I expect a FWHM resolution (for synthesized, ideal pulses) of around 50-65ps at 2 GSPS?

(I'm posting here instead of writing you both privately because I figure there may be broader interest in Daniel's algorithm.)

-Bill

 

    Reply  Fri Apr 12 08:38:17 2013, Stefan Ritt, code/details for optimal DRS4 timing calibration? 

Bill Ashmanskas wrote:

Hi Stefan,

Is either some example code or a detailed written description available for the improved DRS4 timing-calibration algorithm described by Daniel Stricker-Shaver at MIC 2012?  I think you told me that you had verified the results with your own test set-up, so I figure there must be at least two sets of code in existence to implement this calibration.  (I have Daniel's presentation slides.)

I managed to find a ping-pong distribution of cell widths that looks quite similar to that shown in Daniel's slides, using an algorithm similar to the technique one uses to find radial offsets in a tracking chamber (i.e. using residuals weighted by track slope), but I'd rather use the method with which you and Daniel have already found good results.  (The attached graph shows in black the histogram of cell widths for essentially the algorithm used in DRS.cpp/DRSBoard::AnalyzeWF, and in blue the histogram of cell widths extracted from the slope-weighted residuals for a periodic reference signal.)

By the way, since Daniel finds a FWHM coincidence-timing resolution around 20-25ps at 5 GSPS (for perfectly identical pulses), should I expect a FWHM resolution (for synthesized, ideal pulses) of around 50-65ps at 2 GSPS?

(I'm posting here instead of writing you both privately because I figure there may be broader interest in Daniel's algorithm.)

-Bill

 

Hi Bill,

there are several reasons why we have not yet published Daniel's method (I'm in constant contact with him).

1. The method still changes, becomes simpler and more accurate. Originally he used sine waves with varying frequency, which you only get from an external function oscillator. Currently, we found that a single frequency could do a similar, maybe even better job. The current result is much better than the 20-25ps quoted at MIC 2012.

2. Daniel found out that for the ultimate resolution you have to calibrate each channel inside a chip separately. I do understand in meantime the reason for that. So I plan for a V5 evaluation board, which contains means of sending a log-jitter clock to all channels. This board is in test phase and will be made available once it's working as expected.

So my plan is to finish the V5 board and implement the best possible timing calibration on it. Daniel achieved already <5 ps RMS (!) independent of the delay between the two optimal pulses (up to 50 ns). This is actually better than what you can do with a high-end oscilloscope, since scopes have internal interleaving and similar problems due to aliasing etc. than the DRS chip, but scope manufacturers do not put such an emphasis on accurate timing measurements. Once we can reproduce the 5 ps result with the evaluation board, we will publish it. When we found the optimal method, we plan to write a paper about it and explain everything in great detail. We will also be at Seoul for MIC 2013. I'm topic convener there for the session "Digitalization, Acquisition, and Signal Processing Technologies". So probably we will put the DRS4 timing talk there, since it's of more general interest not only to medical applications (and honestly, for a 150 ps TOF-PET you do not need a 5 ps electronics resolution). So stay tuned!

/Stefan

Entry  Mon Apr 22 15:33:28 2013, Benjamin LeGeyt, effect of jitter/alignment between SRCLK and ADC clock 

Hello!
let me apologize in advance if this has already been covered somewhere and I missed it. 


I have a question about a statement made regarding the ADC clock in the evaluation board v4.0 manual.  At the bottom or page 23 there is a mention of jitter between the SRCLK signal and the ADC clock causing a baseline variation in the sampled output of up to a few mV.  Is there any more information out there about this?  I find this confusing for the following reason: If the DRS output has mostly settled after 28ns and the signal that is being sampled is a DC signal, I don't understand why an aperture jitter in the sampling ADC should cause a voltage error in the measured signal.  I already know about the possibility of noise spikes every 32 samples if these clocks are not properly aligned, though I don't know the origin of those spikes.  are these two things related?

 

Many Thanks!
 

    Reply  Mon Apr 22 15:52:53 2013, Stefan Ritt, effect of jitter/alignment between SRCLK and ADC clock adc_phase.jpg

Benjamin LeGeyt wrote:

Hello!
let me apologize in advance if this has already been covered somewhere and I missed it. 


I have a question about a statement made regarding the ADC clock in the evaluation board v4.0 manual.  At the bottom or page 23 there is a mention of jitter between the SRCLK signal and the ADC clock causing a baseline variation in the sampled output of up to a few mV.  Is there any more information out there about this?  I find this confusing for the following reason: If the DRS output has mostly settled after 28ns and the signal that is being sampled is a DC signal, I don't understand why an aperture jitter in the sampling ADC should cause a voltage error in the measured signal.  I already know about the possibility of noise spikes every 32 samples if these clocks are not properly aligned, though I don't know the origin of those spikes.  are these two things related?

Many Thanks!

Hi Benjamin,

In principle you are right, for a DC signal that should not matter. But in reality the DRS4 output signal is not constant even for a DC signal. When you switch from one sampling cell to another during readout, there is something called "charge injection". This causes the output to change up to several 10 mV. After 28 ns this is mostly settled, but not completely, since the DRS4 output driver has a relatively low bandwidth (~50 MHz). Furthermore, the signal line between the DRS4 and the ADC is not terminated, so you have some reflections going forth and back. In addition, you have some crosstalk from the SRCLK signal. So it's better that you sample on each cycle at exactly the same time. Here you see a plot of that (green: DRS4 output, blue: ADC clock, yellow SRCLK):

adc_phase.jpg 

Entry  Tue May 21 12:39:00 2013, Enrico Conti, mac osx 10.6 
Hi,

I would like to use the DRS4 with my macbook pro running osx 10.6.8.
I have installed the wxWidgets and the libusb-1.0 libraries and I am using the Linux code vers. 4.0.1. After
compilation, the following errors come out:

ld: warning: in musbstd.o, file was built for unsupported file format which is not the architecture being linked
(i386)
ld: warning: in mxml.o, file was built for unsupported file format which is not the architecture being linked (i386)
....
....
ld: warning: in main.o, file was built for unsupported file format which is not the architecture being linked (i386)
Undefined symbols:
  "_main", referenced from:
      start in crt1.10.6.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [drsosc] Error 1


Do you have any idea on how to solve the problem ?? or maybe do you have a package working with osx 10.6 ? I
remember to have seen, long time ago, a package that could work with 10.6 (or 10.5 ?), but I cannot find it now
(but maybe I remember wrong).

Thanks for any help,

Enrico
    Reply  Tue May 21 13:25:41 2013, Stefan Ritt, mac osx 10.6 
> Hi,
> 
> I would like to use the DRS4 with my macbook pro running osx 10.6.8.
> I have installed the wxWidgets and the libusb-1.0 libraries and I am using the Linux code vers. 4.0.1. After
> compilation, the following errors come out:
> 
> ld: warning: in musbstd.o, file was built for unsupported file format which is not the architecture being linked
> (i386)
> ld: warning: in mxml.o, file was built for unsupported file format which is not the architecture being linked (i386)
> ....
> ....
> ld: warning: in main.o, file was built for unsupported file format which is not the architecture being linked (i386)
> Undefined symbols:
>   "_main", referenced from:
>       start in crt1.10.6.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make: *** [drsosc] Error 1
> 
> 
> Do you have any idea on how to solve the problem ?? or maybe do you have a package working with osx 10.6 ? I
> remember to have seen, long time ago, a package that could work with 10.6 (or 10.5 ?), but I cannot find it now
> (but maybe I remember wrong).
> 
> Thanks for any help,
> 
> Enrico

Can it be that you have a old PowerPC MAC? I have no experience with that, but probably you have to adjust the Makefile
ans set some flags correctly for PPC instead of Intel.

/Stefan
       Reply  Tue May 21 17:45:05 2013, Enrico Conti, mac osx 10.6 
> 
> Can it be that you have a old PowerPC MAC? I have no experience with that, but probably you have to adjust the Makefile
> ans set some flags correctly for PPC instead of Intel.
> 
> /Stefan


No, I have a MacBook Pro 2.8 GHz Intel Core 2 Duo.
    Reply  Tue May 21 13:32:13 2013, Martin Petriska, mac osx 10.6 
> Hi,
> 
> I would like to use the DRS4 with my macbook pro running osx 10.6.8.
> I have installed the wxWidgets and the libusb-1.0 libraries and I am using the Linux code vers. 4.0.1. After
> compilation, the following errors come out:
> 
> ld: warning: in musbstd.o, file was built for unsupported file format which is not the architecture being linked
> (i386)
> ld: warning: in mxml.o, file was built for unsupported file format which is not the architecture being linked (i386)
> ....
> ....
> ld: warning: in main.o, file was built for unsupported file format which is not the architecture being linked (i386)
> Undefined symbols:
>   "_main", referenced from:
>       start in crt1.10.6.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make: *** [drsosc] Error 1
> 
> 
> Do you have any idea on how to solve the problem ?? or maybe do you have a package working with osx 10.6 ? I
> remember to have seen, long time ago, a package that could work with 10.6 (or 10.5 ?), but I cannot find it now
> (but maybe I remember wrong).
> 
> Thanks for any help,
> 
> Enrico

it looks like 64bit vs 32bit problem, you have to compile all libraries for the same architecture. Maybe, make clean to 
remove all precompiled object files .o and recompile it again. Try to compile first that simple example without wxWidgets.

Martin
       Reply  Tue May 21 17:48:45 2013, Enrico Conti, mac osx 10.6 
> 
> it looks like 64bit vs 32bit problem, you have to compile all libraries for the same architecture. Maybe, make clean to 
> remove all precompiled object files .o and recompile it again. Try to compile first that simple example without wxWidgets.
> 
> Martin


Good point, but all libraries are already compiled to 32 bits, since the laptop is running at 32 bits. Unless you mean that I
have to convert to 64 bits, but this means to change all content of the PC, and I don't want to do this. Can the applications
run with 32 bits or do they need 64 ? 

Thanks,
Enrico
          Reply  Tue May 21 17:51:09 2013, Stefan Ritt, mac osx 10.6 
> > 
> > it looks like 64bit vs 32bit problem, you have to compile all libraries for the same architecture. Maybe, make clean to 
> > remove all precompiled object files .o and recompile it again. Try to compile first that simple example without wxWidgets.
> > 
> > Martin
> 
> 
> Good point, but all libraries are already compiled to 32 bits, since the laptop is running at 32 bits. Unless you mean that I
> have to convert to 64 bits, but this means to change all content of the PC, and I don't want to do this. Can the applications
> run with 32 bits or do they need 64 ? 
> 
> Thanks,
> Enrico

There is no specific reason to run it on 64 bits, so just all libraries have to match, that's all. But the original Makefile has been written for 64 bits, so it might need some 
adjustments.

/Stefan
             Reply  Tue May 21 18:30:11 2013, Enrico Conti, mac osx 10.6 
> > > 
> > > it looks like 64bit vs 32bit problem, you have to compile all libraries for the same architecture. Maybe, make clean to 
> > > remove all precompiled object files .o and recompile it again. Try to compile first that simple example without wxWidgets.
> > > 
> > > Martin
> > 
> > 
> > Good point, but all libraries are already compiled to 32 bits, since the laptop is running at 32 bits. Unless you mean that I
> > have to convert to 64 bits, but this means to change all content of the PC, and I don't want to do this. Can the applications
> > run with 32 bits or do they need 64 ? 
> > 
> > Thanks,
> > Enrico
> 


> There is no specific reason to run it on 64 bits, 

Good.

> so just all libraries have to match, that's all. But the original Makefile has been written for 64 bits, so it might need some 
> adjustments.

Ok, but I don't understand where is the point to correct. 64 bits do not appear explicitally (at least to me, who am not a drake of programming ...) 
neither in the Makefile neither in the (few) source files I have examined.

Thanks again,
Enrico
             Reply  Fri May 24 17:58:07 2013, Enrico Conti, mac osx 10.6 
> > > 
> > > it looks like 64bit vs 32bit problem, you have to compile all libraries for the same architecture. Maybe, make clean to 
> > > remove all precompiled object files .o and recompile it again. Try to compile first that simple example without wxWidgets.
> > > 
> > > Martin
> > 
> > 
> > Good point, but all libraries are already compiled to 32 bits, since the laptop is running at 32 bits. Unless you mean that I
> > have to convert to 64 bits, but this means to change all content of the PC, and I don't want to do this. Can the applications
> > run with 32 bits or do they need 64 ? 
> > 
> > Thanks,
> > Enrico
> 
> There is no specific reason to run it on 64 bits, so just all libraries have to match, that's all. But the original Makefile has been written for 64 bits, so it might need some 
> adjustments.
> 
> /Stefan

Hi Stefan,
   I made some progress. Understood what was wrong in the make phase. You have only to add the option -arch i386 in the CFLAGS line of the makefile.
Then the make is ok, it produces the 3 executables. drs_exam and drscl seem to work correctly. 
DRSOsc.app does not work as app, in the sense that if you click it, an error message comes saying "You can't use this version of the application DRSOsc.app with 
this version of Mac OS X. You have Mac OSX 10.6.8. The application requires Mac OS X 10.7 or later. "
If you execute drsosc from the terminal, the graphical window pops up, the waveform is displayed, but you don't have access to the graphical interface, no button works, you can't do
anything. To quit the app, you have to kill it from the terminal with the kill command.
But anyway is a progress with respect to yestarday.
Any idea/suggestion to overcome the above problems ? I thought it is a problem with the graphical library (xwWidgets) but I have checked it, it's ok, I have also reinstalled it
(release 2.8.12_3) but nothing changed.

PS. the chip test output (done with the drscl ) is the following (see below). Is it normal or what ? THANKS.

B0> ct
Press 'q' to quit, any other key to repeat test.

Max. frequency is 5.1 GHz
Cell error on channel 1, cell 5: -137.6 mV instead 0 mV
Chip Error!

Max. frequency is 5.1 GHz
Cell error on channel 1, cell 5: -129.4 mV instead 0 mV
Chip Error!
                Reply  Fri May 24 18:20:14 2013, Stefan Ritt, mac osx 10.6 
> I made some progress. Understood what was wrong in the make phase. You have only to add the option -arch i386 in the CFLAGS line of the makefile.
> Then the make is ok, it produces the 3 executables. drs_exam and drscl seem to work correctly. 
> DRSOsc.app does not work as app, in the sense that if you click it, an error message comes saying "You can't use this version of the application DRSOsc.app with 
> this version of Mac OS X. You have Mac OSX 10.6.8. The application requires Mac OS X 10.7 or later. "
> If you execute drsosc from the terminal, the graphical window pops up, the waveform is displayed, but you don't have access to the graphical interface, no button works, you can't do
> anything. To quit the app, you have to kill it from the terminal with the kill command.

To run an executable as an app, you have to put it into a certain directory structure. The Makefile has the target "make app" which exactly does that. It executes following code:

DRSOsc.app: drsosc
        -mkdir DRSOsc.app
        -mkdir DRSOsc.app/Contents
        -mkdir DRSOsc.app/Contents/MacOS
        -mkdir DRSOsc.app/Contents/Resources
        -mkdir DRSOsc.app/Contents/Resources/English.lproj
        echo 'APPL????' > DRSOsc.app/Contents/PkgInfo
        cp drsosc.xcodeproj/Info-processed.plist DRSOsc.app/Contents/Info.plist
        cp drsosc DRSOsc.app/Contents/MacOS/DRSOsc
        cp drsosc.xcodeproj/DRSOsc.icns DRSOsc.app/Contents/Resources

You can also do this manually. You will then see the subdirectly DRSOsc.app actually as an App icon (you don't see it as a subdirectory in the Finder).  That's the way Apple has chosen to do this.

The chip test facility has been made for a certain test board we use for chip testing. It has a feature that is not present in the evaluation board. I have to disable that command there.

Best regards,
Stefan
                   Reply  Sat May 25 12:45:46 2013, Enrico Conti, mac osx 10.6 
> > I made some progress. Understood what was wrong in the make phase. You have only to add the option -arch i386 in the CFLAGS line of the makefile.
> > Then the make is ok, it produces the 3 executables. drs_exam and drscl seem to work correctly. 
> > DRSOsc.app does not work as app, in the sense that if you click it, an error message comes saying "You can't use this version of the application DRSOsc.app with 
> > this version of Mac OS X. You have Mac OSX 10.6.8. The application requires Mac OS X 10.7 or later. "
> > If you execute drsosc from the terminal, the graphical window pops up, the waveform is displayed, but you don't have access to the graphical interface, no button works, you can't do
> > anything. To quit the app, you have to kill it from the terminal with the kill command.
> 
> To run an executable as an app, you have to put it into a certain directory structure. The Makefile has the target "make app" which exactly does that. It executes following code:
> 
> DRSOsc.app: drsosc
>         -mkdir DRSOsc.app
>         -mkdir DRSOsc.app/Contents
>         -mkdir DRSOsc.app/Contents/MacOS
>         -mkdir DRSOsc.app/Contents/Resources
>         -mkdir DRSOsc.app/Contents/Resources/English.lproj
>         echo 'APPL????' > DRSOsc.app/Contents/PkgInfo
>         cp drsosc.xcodeproj/Info-processed.plist DRSOsc.app/Contents/Info.plist
>         cp drsosc DRSOsc.app/Contents/MacOS/DRSOsc
>         cp drsosc.xcodeproj/DRSOsc.icns DRSOsc.app/Contents/Resources
> 
> You can also do this manually. You will then see the subdirectly DRSOsc.app actually as an App icon (you don't see it as a subdirectory in the Finder).  That's the way Apple has chosen to do this.
> 
> The chip test facility has been made for a certain test board we use for chip testing. It has a feature that is not present in the evaluation board. I have to disable that command there.
> 
> Best regards,
> Stefan

Hi Stefan,
yes, the makefile has already the recipe to create the app. For OSX 10.6 a obvious modification must be done in the info.plist file. Then everything goes right. Now I have the DRSOsc application
running on my mac with 10.6.
Thanks for the help.
Best regards,
Enrico
Entry  Wed Feb 22 11:36:51 2012, sonal, DRS4- analog pulse counting 

Hello Sir,

Regarding to analog pulse counting by using DRS4 Rev.2.0 board, you have said that "There is a way to perform the counting dead time free, but that requires the V4 board, which has a hardware comparator on all four channels (The V2 board has only one comparator and a multiplexer). The output of these comparators go directly to the FPGA, which can then trigger on these signals. In principle one could implement a hardware counter in the FPGA, which works practically dead time free. But this requires a new firmware which has to be written. Either you do it yourself using the Xilinx development tools, or you wait until I find some time to implement this, which could take a couple of weeks or even months."

I am interested in it. I have DRS4 Rev.2.0 board. I have FPGA and Microcontroller firmware for this board. How can I implement this concept of counting pulses?

 


    Reply  Fri Feb 24 15:52:43 2012, Stefan Ritt, DRS4- analog pulse counting 

sonal wrote:

Hello Sir,

Regarding to analog pulse counting by using DRS4 Rev.2.0 board, you have said that "There is a way to perform the counting dead time free, but that requires the V4 board, which has a hardware comparator on all four channels (The V2 board has only one comparator and a multiplexer). The output of these comparators go directly to the FPGA, which can then trigger on these signals. In principle one could implement a hardware counter in the FPGA, which works practically dead time free. But this requires a new firmware which has to be written. Either you do it yourself using the Xilinx development tools, or you wait until I find some time to implement this, which could take a couple of weeks or even months."

I am interested in it. I have DRS4 Rev.2.0 board. I have FPGA and Microcontroller firmware for this board. How can I implement this concept of counting pulses?

 


As I said above, you need a V4 board which has the four hardware comparators mounted. You cannot do that with the V2 board, even with a firmware upgrade.

The firmware upgrade for the V4 board is not yet ready and I won't have time for that in the next 3-4 weeks, but afterwards maybe.

Best regards,

Stefan 

       Reply  Wed Feb 29 06:46:47 2012, Sonal, DRS4- analog pulse counting 

Stefan Ritt wrote:

sonal wrote:

Hello Sir,

Regarding to analog pulse counting by using DRS4 Rev.2.0 board, you have said that "There is a way to perform the counting dead time free, but that requires the V4 board, which has a hardware comparator on all four channels (The V2 board has only one comparator and a multiplexer). The output of these comparators go directly to the FPGA, which can then trigger on these signals. In principle one could implement a hardware counter in the FPGA, which works practically dead time free. But this requires a new firmware which has to be written. Either you do it yourself using the Xilinx development tools, or you wait until I find some time to implement this, which could take a couple of weeks or even months."

I am interested in it. I have DRS4 Rev.2.0 board. I have FPGA and Microcontroller firmware for this board. How can I implement this concept of counting pulses?

 


As I said above, you need a V4 board which has the four hardware comparators mounted. You cannot do that with the V2 board, even with a firmware upgrade.

The firmware upgrade for the V4 board is not yet ready and I won't have time for that in the next 3-4 weeks, but afterwards maybe.

Best regards,

Stefan 

 Thank you for your response.

The DRS4 Rev.2.0 with one Multiplexer and a Comparator I think may be is ok for me. Since I wanted to implement counter in FPGA, I have gone through firmware but its very difficult for me to get the flow of data from DRS to USB. Could you help me to get familiar with or to get flow of the data from DRS to the USB?

 

Thank You,

Sonal

          Reply  Thu Mar 1 19:22:26 2012, Stefan Ritt, DRS4- analog pulse counting 

Sonal wrote:

The DRS4 Rev.2.0 with one Multiplexer and a Comparator I think may be is ok for me. Since I wanted to implement counter in FPGA, I have gone through firmware but its very difficult for me to get the flow of data from DRS to USB. Could you help me to get familiar with or to get flow of the data from DRS to the USB?

Hi Sonai,

unfortunately I cannot teach you VHDL, you should take a course somewhere. Actually you don't have to touch the USB part, you just have to implement a new register in the firmware, and connect it to a VHDL counter attached to the trigger input. I will do this in a couple of weeks myself, so you can also just wait. I will however only do this for the V4 board, so you have to port it back to the V2 firmware.

Best regards,

Stefan

             Reply  Wed Mar 6 12:35:38 2013, Osip Lishilin, DRS4- analog pulse counting 

Hello, Stefan. Have you implemented pulse counting yet?

Best, Osip.

                Reply  Wed Mar 6 12:37:14 2013, Stefan Ritt, DRS4- analog pulse counting 

Osip Lishilin wrote:

Hello, Stefan. Have you implemented pulse counting yet?

Best, Osip.

Nope. 

                   Reply  Mon May 20 08:42:16 2013, Osip Lishilin, DRS4- analog pulse counting 

Stefan Ritt wrote:

Osip Lishilin wrote:

Hello, Stefan. Have you implemented pulse counting yet?

Best, Osip.

Nope. 

 Will it be done in the foreseeable future?

                      Reply  Sat May 25 21:03:22 2013, Stefan Ritt, DRS4- analog pulse counting 

Osip Lishilin wrote:

Stefan Ritt wrote:

Osip Lishilin wrote:

Hello, Stefan. Have you implemented pulse counting yet?

Best, Osip.

Nope. 

 Will it be done in the foreseeable future?

Yes. I will announce it in the forum. 

Entry  Fri Jul 5 12:46:45 2013, Hermann-Josef Mathes, Missing methods in drs-4.0.1.tar.gz 

Hi,

while trying to create python bindings for the DRS stuff using SWIG 2.0.4, two undefined methods prevent the python interpreter from loading the generated shared library. These methods are:

  • int DRSBoard::SetADCActive(unsigned char)
  • bool ResponseCalibration::Calibrate(unsigned int,unsigned int,float *,float *,float,bool)

Can we safely removed those methods from the DRS header files or (what I have actually done) is it better to fake some empty implementation in the input file to SWIG?

Another minor issue is that the python interpreter always terminates with a SegFault after script termination. I had not yet time to track that down...

Thanks & regards

Hermann-Josef

 

    Reply  Sat Jul 6 06:10:38 2013, Stefan Ritt, Missing methods in drs-4.0.1.tar.gz 

Hermann-Josef Mathes wrote:

Hi,

while trying to create python bindings for the DRS stuff using SWIG 2.0.4, two undefined methods prevent the python interpreter from loading the generated shared library. These methods are:

  • int DRSBoard::SetADCActive(unsigned char)
  • bool ResponseCalibration::Calibrate(unsigned int,unsigned int,float *,float *,float,bool)

Can we safely removed those methods from the DRS header files or (what I have actually done) is it better to fake some empty implementation in the input file to SWIG?

Another minor issue is that the python interpreter always terminates with a SegFault after script termination. I had not yet time to track that down...

Thanks & regards

Hermann-Josef

 

Thanks for pointing that out. My C++ compiler does not complain about such errors. You can safely remove these functions. I did so as well, so future versions will not contain that any more.

/Stefan 

Entry  Tue Jul 9 11:40:00 2013, Dmitry Hits, cannot save in binary format 

Hi,

I would like to save the waveform in a binary format. When I click Save then change format from xml to dat in the menu. I still get xml format but with dat extension.

what I am missing?

Thank you,

Dmitry.

 

    Reply  Tue Jul 9 12:23:06 2013, Stefan Ritt, cannot save in binary format 

Dmitry Hits wrote:

Hi,

I would like to save the waveform in a binary format. When I click Save then change format from xml to dat in the menu. I still get xml format but with dat extension.

what I am missing?

Thank you,

Dmitry.

Version 4.0.1 has a problem there. Please use 4.0.0. If you can compile the program yourself, just change this line:

--- DOFrame.cpp (revision 20656)
+++ DOFrame.cpp (revision 20655)
@@ -517,7 +517,7 @@
       if (!filename.empty()) {
          m_btSave->SetLabel(_T("Close"));
          m_btSave->SetToolTip(_T("Stop saving waveforms"));
-         if (filename.Find(_T(".")) != wxNOT_FOUND) {
+         if (filename.Find(_T(".xml")) != wxNOT_FOUND) {
             m_WFfd = 0;
             m_WFFile = mxml_open_file(filename.char_str());
             if (m_WFFile)

 

       Reply  Tue Jul 9 14:00:49 2013, Dmitry Hits, cannot save in binary format 

Stefan Ritt wrote:

Dmitry Hits wrote:

Hi,

I would like to save the waveform in a binary format. When I click Save then change format from xml to dat in the menu. I still get xml format but with dat extension.

what I am missing?

Thank you,

Dmitry.

Version 4.0.1 has a problem there. Please use 4.0.0. If you can compile the program yourself, just change this line:

--- DOFrame.cpp (revision 20656)
+++ DOFrame.cpp (revision 20655)
@@ -517,7 +517,7 @@
       if (!filename.empty()) {
          m_btSave->SetLabel(_T("Close"));
          m_btSave->SetToolTip(_T("Stop saving waveforms"));
-         if (filename.Find(_T(".")) != wxNOT_FOUND) {
+         if (filename.Find(_T(".xml")) != wxNOT_FOUND) {
             m_WFfd = 0;
             m_WFFile = mxml_open_file(filename.char_str());
             if (m_WFFile)

 

 Thanks that fixed it!

Dmitry

Entry  Tue Jul 23 22:31:08 2013, alonzi, Evaluation Board Behavior Screenshot.pngdata_problem.png

Working with the DRS evaluation board we noticed some funny behavior: See attatchment 1. In about 1% of scope traces we see the first and last bin take on a value substantially different from the baseline, note the small spikes on the end of the traces. These spikes occur across all channels and either appear in all channels or in none. Attachment two shows what several thousand scope traces look like. You can clearly see that some of the traces are offset from the normal base line. Has anyone observed this behavior before? Any ideas?

see https://muon.npl.washington.edu/elog/g2/Detectors/550 for full discussion. 

    Reply  Tue Jul 23 22:35:08 2013, Stefan Ritt, Evaluation Board Behavior 

alonzi wrote:

Working with the DRS evaluation board we noticed some funny behavior: See attatchment 1. In about 1% of scope traces we see the first and last bin take on a value substantially different from the baseline, note the small spikes on the end of the traces. These spikes occur across all channels and either appear in all channels or in none. Attachment two shows what several thousand scope traces look like. You can clearly see that some of the traces are offset from the normal base line. Has anyone observed this behavior before? Any ideas?

see https://muon.npl.washington.edu/elog/g2/Detectors/550 for full discussion. 

Actually the first and last sample are even more off the baseline, so I cut them out in software in the DRSOscilloscope. So actually the chip has only 1022 "usable" cells. It might happen in some rare cases that more cells are affected, although I have not yet seen this (maybe I did not look close enough). So I propose that you cut out one more bin at the beginning and the end, so a total of 1020 cells, and you should be fine.

/Stefan 

       Reply  Tue Jul 23 22:42:31 2013, alonzi, Evaluation Board Behavior 

Stefan Ritt wrote:

alonzi wrote:

Working with the DRS evaluation board we noticed some funny behavior: See attatchment 1. In about 1% of scope traces we see the first and last bin take on a value substantially different from the baseline, note the small spikes on the end of the traces. These spikes occur across all channels and either appear in all channels or in none. Attachment two shows what several thousand scope traces look like. You can clearly see that some of the traces are offset from the normal base line. Has anyone observed this behavior before? Any ideas?

see https://muon.npl.washington.edu/elog/g2/Detectors/550 for full discussion. 

Actually the first and last sample are even more off the baseline, so I cut them out in software in the DRSOscilloscope. So actually the chip has only 1022 "usable" cells. It might happen in some rare cases that more cells are affected, although I have not yet seen this (maybe I did not look close enough). So I propose that you cut out one more bin at the beginning and the end, so a total of 1020 cells, and you should be fine.

/Stefan 

 Thanks for the quick reply. Our quick fix was to do just that. 

          Reply  Thu Jul 25 01:31:29 2013, Andrey Kuznetsov, Evaluation Board Behavior 

alonzi wrote:

Stefan Ritt wrote:

alonzi wrote:

Working with the DRS evaluation board we noticed some funny behavior: See attatchment 1. In about 1% of scope traces we see the first and last bin take on a value substantially different from the baseline, note the small spikes on the end of the traces. These spikes occur across all channels and either appear in all channels or in none. Attachment two shows what several thousand scope traces look like. You can clearly see that some of the traces are offset from the normal base line. Has anyone observed this behavior before? Any ideas?

see https://muon.npl.washington.edu/elog/g2/Detectors/550 for full discussion. 

Actually the first and last sample are even more off the baseline, so I cut them out in software in the DRSOscilloscope. So actually the chip has only 1022 "usable" cells. It might happen in some rare cases that more cells are affected, although I have not yet seen this (maybe I did not look close enough). So I propose that you cut out one more bin at the beginning and the end, so a total of 1020 cells, and you should be fine.

/Stefan 

 Thanks for the quick reply. Our quick fix was to do just that. 

 We've encountered similar issues with board v2.0. Cell #2 across all channels would occasionally go full negative amplitude (0 I guess).

I don't remember if calibration fixed the problem, might have.

Entry  Sun May 26 13:08:52 2013, tmiron alon,  

Hallo,
I'm using DRS4 Evaluation Board Rev 4.0 and I'm trying to change the output of the samples to be an average of  #  measurements (1000 or even more)
during the process I have encountered some difficulties I hope you will be able to help me  with:

1. the DRS chip have 8 channels but the Evaluation board have only 4 channels. does the default mode of the DRS in the Evaluation Board is 1024 bins for each channel or 2048?

2. in the readout mode, does it samples all the 1024 bins waveform from a channel and then move to the next one, or after each bin it move to the next channel?

3. In the file "drs4_eval4_app.vhd", I have a problem finding the names of the signals that represents the registers bits which tell me what is the number of the bin (1-1024) the ADC is reading from the DRS, and the signals

that represents registers A0-A3. can you send me their names? 

 

4. In another matter- is the -0.5V to 0.5V is the  upper and lower  limit of the input (or just a working range), and if not what is the limit for AC?  is there a fuse on the board in case of overload from the input? (I didn't see  it in the User's Manual, but I didn't know if you will mention it there in case there is one).

thanks in advance and have a nice day,

Tmiron

    Reply  Fri Jun 7 10:22:48 2013, Stefan Ritt,  

tmiron alon wrote:

Hallo,
I'm using DRS4 Evaluation Board Rev 4.0 and I'm trying to change the output of the samples to be an average of  #  measurements (1000 or even more)
during the process I have encountered some difficulties I hope you will be able to help me  with:

1. the DRS chip have 8 channels but the Evaluation board have only 4 channels. does the default mode of the DRS in the Evaluation Board is 1024 bins for each channel or 2048?

2. in the readout mode, does it samples all the 1024 bins waveform from a channel and then move to the next one, or after each bin it move to the next channel?

3. In the file "drs4_eval4_app.vhd", I have a problem finding the names of the signals that represents the registers bits which tell me what is the number of the bin (1-1024) the ADC is reading from the DRS, and the signals

that represents registers A0-A3. can you send me their names? 

 

4. In another matter- is the -0.5V to 0.5V is the  upper and lower  limit of the input (or just a working range), and if not what is the limit for AC?  is there a fuse on the board in case of overload from the input? (I didn't see  it in the User's Manual, but I didn't know if you will mention it there in case there is one).

thanks in advance and have a nice day,

Tmiron

1. All 8 channels are read out, but only 4 are displayed in the oscilloscope.

2. It reads all 1024 bins from a channel, then switch to the next channel.

3. The ADC readout happens in lines 1576+. The register for the sample count is drs_sample_count, and the signal for the address is drs_addr.

4. The evaluation board manual explicitly mentions the maximum allowed input range on page 5.

/Stefan 

       Reply  Fri Jun 7 11:44:17 2013, tmiron alon, thank you 

Stefan Ritt wrote:

tmiron alon wrote:

Hallo,
I'm using DRS4 Evaluation Board Rev 4.0 and I'm trying to change the output of the samples to be an average of  #  measurements (1000 or even more)
during the process I have encountered some difficulties I hope you will be able to help me  with:

1. the DRS chip have 8 channels but the Evaluation board have only 4 channels. does the default mode of the DRS in the Evaluation Board is 1024 bins for each channel or 2048?

2. in the readout mode, does it samples all the 1024 bins waveform from a channel and then move to the next one, or after each bin it move to the next channel?

3. In the file "drs4_eval4_app.vhd", I have a problem finding the names of the signals that represents the registers bits which tell me what is the number of the bin (1-1024) the ADC is reading from the DRS, and the signals

that represents registers A0-A3. can you send me their names? 

 

4. In another matter- is the -0.5V to 0.5V is the  upper and lower  limit of the input (or just a working range), and if not what is the limit for AC?  is there a fuse on the board in case of overload from the input? (I didn't see  it in the User's Manual, but I didn't know if you will mention it there in case there is one).

thanks in advance and have a nice day,

Tmiron

1. All 8 channels are read out, but only 4 are displayed in the oscilloscope.

2. It reads all 1024 bins from a channel, then switch to the next channel.

3. The ADC readout happens in lines 1576+. The register for the sample count is drs_sample_count, and the signal for the address is drs_addr.

4. The evaluation board manual explicitly mentions the maximum allowed input range on page 5.

/Stefan 

Thank you for the answer.

Have a nice week,

Tmiron.

       Reply  Mon Jun 10 14:09:13 2013, tmiron alon, add an average ability to the Scope 

Stefan Ritt wrote:

tmiron alon wrote:

Hallo,
I'm using DRS4 Evaluation Board Rev 4.0 and I'm trying to change the output of the samples to be an average of  #  measurements (1000 or even more)
during the process I have encountered some difficulties I hope you will be able to help me  with:

1. the DRS chip have 8 channels but the Evaluation board have only 4 channels. does the default mode of the DRS in the Evaluation Board is 1024 bins for each channel or 2048?

2. in the readout mode, does it samples all the 1024 bins waveform from a channel and then move to the next one, or after each bin it move to the next channel?

3. In the file "drs4_eval4_app.vhd", I have a problem finding the names of the signals that represents the registers bits which tell me what is the number of the bin (1-1024) the ADC is reading from the DRS, and the signals

that represents registers A0-A3. can you send me their names? 

 

4. In another matter- is the -0.5V to 0.5V is the  upper and lower  limit of the input (or just a working range), and if not what is the limit for AC?  is there a fuse on the board in case of overload from the input? (I didn't see  it in the User's Manual, but I didn't know if you will mention it there in case there is one).

thanks in advance and have a nice day,

Tmiron

1. All 8 channels are read out, but only 4 are displayed in the oscilloscope.

2. It reads all 1024 bins from a channel, then switch to the next channel.

3. The ADC readout happens in lines 1576+. The register for the sample count is drs_sample_count, and the signal for the address is drs_addr.

4. The evaluation board manual explicitly mentions the maximum allowed input range on page 5.

/Stefan 

 Hi Stefan,

I'm trying to add the averaging feature to the oscilloscope instead. I have a basic knowledge in C++ so I'm having problem finding the initial place (places) of the data acquisition. furthermore, I saw you already made an averaging possibility for some of the features in the program at the measure window.
Can you please tell we in which of the programs of the Scope (and in what line if possible) can I find the initial\main data acquisition so I could follow it from there, and where is the location of the averaging function you already made?

have a nice week,

Tmiron

          Reply  Mon Jun 10 16:24:21 2013, Stefan Ritt, add an average ability to the Scope 

tmiron alon wrote:

Stefan Ritt wrote:

tmiron alon wrote:

Hallo,
I'm using DRS4 Evaluation Board Rev 4.0 and I'm trying to change the output of the samples to be an average of  #  measurements (1000 or even more)
during the process I have encountered some difficulties I hope you will be able to help me  with:

1. the DRS chip have 8 channels but the Evaluation board have only 4 channels. does the default mode of the DRS in the Evaluation Board is 1024 bins for each channel or 2048?

2. in the readout mode, does it samples all the 1024 bins waveform from a channel and then move to the next one, or after each bin it move to the next channel?

3. In the file "drs4_eval4_app.vhd", I have a problem finding the names of the signals that represents the registers bits which tell me what is the number of the bin (1-1024) the ADC is reading from the DRS, and the signals

that represents registers A0-A3. can you send me their names? 

 

4. In another matter- is the -0.5V to 0.5V is the  upper and lower  limit of the input (or just a working range), and if not what is the limit for AC?  is there a fuse on the board in case of overload from the input? (I didn't see  it in the User's Manual, but I didn't know if you will mention it there in case there is one).

thanks in advance and have a nice day,

Tmiron

1. All 8 channels are read out, but only 4 are displayed in the oscilloscope.

2. It reads all 1024 bins from a channel, then switch to the next channel.

3. The ADC readout happens in lines 1576+. The register for the sample count is drs_sample_count, and the signal for the address is drs_addr.

4. The evaluation board manual explicitly mentions the maximum allowed input range on page 5.

/Stefan 

 Hi Stefan,

I'm trying to add the averaging feature to the oscilloscope instead. I have a basic knowledge in C++ so I'm having problem finding the initial place (places) of the data acquisition. furthermore, I saw you already made an averaging possibility for some of the features in the program at the measure window.
Can you please tell we in which of the programs of the Scope (and in what line if possible) can I find the initial\main data acquisition so I could follow it from there, and where is the location of the averaging function you already made?

have a nice week,

Tmiron

The averaging possibility in the measure window is just a "place holder" for future extensions, which are not yet implemented.

A good point to implement averaging is in the function Osci::ReadWaveforms() in Osci.cpp.

/Stefan 

             Reply  Thu Jul 4 08:32:11 2013, tmiron alon, add an average ability to the Scope 

Stefan Ritt wrote:

tmiron alon wrote:

Stefan Ritt wrote:

tmiron alon wrote:

Hallo,
I'm using DRS4 Evaluation Board Rev 4.0 and I'm trying to change the output of the samples to be an average of  #  measurements (1000 or even more)
during the process I have encountered some difficulties I hope you will be able to help me  with:

1. the DRS chip have 8 channels but the Evaluation board have only 4 channels. does the default mode of the DRS in the Evaluation Board is 1024 bins for each channel or 2048?

2. in the readout mode, does it samples all the 1024 bins waveform from a channel and then move to the next one, or after each bin it move to the next channel?

3. In the file "drs4_eval4_app.vhd", I have a problem finding the names of the signals that represents the registers bits which tell me what is the number of the bin (1-1024) the ADC is reading from the DRS, and the signals

that represents registers A0-A3. can you send me their names? 

 

4. In another matter- is the -0.5V to 0.5V is the  upper and lower  limit of the input (or just a working range), and if not what is the limit for AC?  is there a fuse on the board in case of overload from the input? (I didn't see  it in the User's Manual, but I didn't know if you will mention it there in case there is one).

thanks in advance and have a nice day,

Tmiron

1. All 8 channels are read out, but only 4 are displayed in the oscilloscope.

2. It reads all 1024 bins from a channel, then switch to the next channel.

3. The ADC readout happens in lines 1576+. The register for the sample count is drs_sample_count, and the signal for the address is drs_addr.

4. The evaluation board manual explicitly mentions the maximum allowed input range on page 5.

/Stefan 

 Hi Stefan,

I'm trying to add the averaging feature to the oscilloscope instead. I have a basic knowledge in C++ so I'm having problem finding the initial place (places) of the data acquisition. furthermore, I saw you already made an averaging possibility for some of the features in the program at the measure window.
Can you please tell we in which of the programs of the Scope (and in what line if possible) can I find the initial\main data acquisition so I could follow it from there, and where is the location of the averaging function you already made?

have a nice week,

Tmiron

The averaging possibility in the measure window is just a "place holder" for future extensions, which are not yet implemented.

A good point to implement averaging is in the function Osci::ReadWaveforms() in Osci.cpp.

/Stefan 

Hi Stefan,

I have been trying to compile my changes to the program, but have a problem with the "wxWidgets". can you tell me which version of the wxWidgets and which c++ program did you use to built the drs4's scope program?

I'm using "microsoft visual c++ 2010 express", and the closest I got to compile something was with the wxWidgets 2.8.12 version (It's tell me I'm missing the file "wxmsw28d_core.lib" although I built it).

have a nice day,

Tmiron.

                Reply  Thu Jul 4 08:54:25 2013, Stefan Ritt, add an average ability to the Scope 

tmiron alon wrote:

Stefan Ritt wrote:

tmiron alon wrote:

Stefan Ritt wrote:

tmiron alon wrote:

Hallo,
I'm using DRS4 Evaluation Board Rev 4.0 and I'm trying to change the output of the samples to be an average of  #  measurements (1000 or even more)
during the process I have encountered some difficulties I hope you will be able to help me  with:

1. the DRS chip have 8 channels but the Evaluation board have only 4 channels. does the default mode of the DRS in the Evaluation Board is 1024 bins for each channel or 2048?

2. in the readout mode, does it samples all the 1024 bins waveform from a channel and then move to the next one, or after each bin it move to the next channel?

3. In the file "drs4_eval4_app.vhd", I have a problem finding the names of the signals that represents the registers bits which tell me what is the number of the bin (1-1024) the ADC is reading from the DRS, and the signals

that represents registers A0-A3. can you send me their names? 

 

4. In another matter- is the -0.5V to 0.5V is the  upper and lower  limit of the input (or just a working range), and if not what is the limit for AC?  is there a fuse on the board in case of overload from the input? (I didn't see  it in the User's Manual, but I didn't know if you will mention it there in case there is one).

thanks in advance and have a nice day,

Tmiron

1. All 8 channels are read out, but only 4 are displayed in the oscilloscope.

2. It reads all 1024 bins from a channel, then switch to the next channel.

3. The ADC readout happens in lines 1576+. The register for the sample count is drs_sample_count, and the signal for the address is drs_addr.

4. The evaluation board manual explicitly mentions the maximum allowed input range on page 5.

/Stefan 

 Hi Stefan,

I'm trying to add the averaging feature to the oscilloscope instead. I have a basic knowledge in C++ so I'm having problem finding the initial place (places) of the data acquisition. furthermore, I saw you already made an averaging possibility for some of the features in the program at the measure window.
Can you please tell we in which of the programs of the Scope (and in what line if possible) can I find the initial\main data acquisition so I could follow it from there, and where is the location of the averaging function you already made?

have a nice week,

Tmiron

The averaging possibility in the measure window is just a "place holder" for future extensions, which are not yet implemented.

A good point to implement averaging is in the function Osci::ReadWaveforms() in Osci.cpp.

/Stefan 

Hi Stefan,

I have been trying to compile my changes to the program, but have a problem with the "wxWidgets". can you tell me which version of the wxWidgets and which c++ program did you use to built the drs4's scope program?

I'm using "microsoft visual c++ 2010 express", and the closest I got to compile something was with the wxWidgets 2.8.12 version (It's tell me I'm missing the file "wxmsw28d_core.lib" although I built it).

have a nice day,

Tmiron.

I guess it should work with 2.8.12. Try to compile their examples, and consult their documentation if it does not work. I cannot give support for a package I have not written.

/Stefan 

                   Reply  Thu Jul 4 09:07:24 2013, tmiron alon, add an average ability to the Scope 

Stefan Ritt wrote:

tmiron alon wrote:

Stefan Ritt wrote:

tmiron alon wrote:

Stefan Ritt wrote:

tmiron alon wrote:

Hallo,
I'm using DRS4 Evaluation Board Rev 4.0 and I'm trying to change the output of the samples to be an average of  #  measurements (1000 or even more)
during the process I have encountered some difficulties I hope you will be able to help me  with:

1. the DRS chip have 8 channels but the Evaluation board have only 4 channels. does the default mode of the DRS in the Evaluation Board is 1024 bins for each channel or 2048?

2. in the readout mode, does it samples all the 1024 bins waveform from a channel and then move to the next one, or after each bin it move to the next channel?

3. In the file "drs4_eval4_app.vhd", I have a problem finding the names of the signals that represents the registers bits which tell me what is the number of the bin (1-1024) the ADC is reading from the DRS, and the signals

that represents registers A0-A3. can you send me their names? 

 

4. In another matter- is the -0.5V to 0.5V is the  upper and lower  limit of the input (or just a working range), and if not what is the limit for AC?  is there a fuse on the board in case of overload from the input? (I didn't see  it in the User's Manual, but I didn't know if you will mention it there in case there is one).

thanks in advance and have a nice day,

Tmiron

1. All 8 channels are read out, but only 4 are displayed in the oscilloscope.

2. It reads all 1024 bins from a channel, then switch to the next channel.

3. The ADC readout happens in lines 1576+. The register for the sample count is drs_sample_count, and the signal for the address is drs_addr.

4. The evaluation board manual explicitly mentions the maximum allowed input range on page 5.

/Stefan 

 Hi Stefan,

I'm trying to add the averaging feature to the oscilloscope instead. I have a basic knowledge in C++ so I'm having problem finding the initial place (places) of the data acquisition. furthermore, I saw you already made an averaging possibility for some of the features in the program at the measure window.
Can you please tell we in which of the programs of the Scope (and in what line if possible) can I find the initial\main data acquisition so I could follow it from there, and where is the location of the averaging function you already made?

have a nice week,

Tmiron

The averaging possibility in the measure window is just a "place holder" for future extensions, which are not yet implemented.

A good point to implement averaging is in the function Osci::ReadWaveforms() in Osci.cpp.

/Stefan 

Hi Stefan,

I have been trying to compile my changes to the program, but have a problem with the "wxWidgets". can you tell me which version of the wxWidgets and which c++ program did you use to built the drs4's scope program?

I'm using "microsoft visual c++ 2010 express", and the closest I got to compile something was with the wxWidgets 2.8.12 version (It's tell me I'm missing the file "wxmsw28d_core.lib" although I built it).

have a nice day,

Tmiron.

I guess it should work with 2.8.12. Try to compile their examples, and consult their documentation if it does not work. I cannot give support for a package I have not written.

/Stefan 

My problem is not with wxWidgets itself but with links your program is doing to the wxWidgets. if you can please tell me the wxWidget version you used, I'll use this one instead the version I'm using and I think it will solve the problem.

Tmiron.

                      Reply  Thu Jul 4 09:17:31 2013, Stefan Ritt, add an average ability to the Scope 

tmiron alon wrote:

 

My problem is not with wxWidgets itself but with links your program is doing to the wxWidgets. if you can please tell me the wxWidget version you used, I'll use this one instead the version I'm using and I think it will solve the problem.

Tmiron.

I currently use version 2.9.4, but chances are high that it will work with 2.8.12.

/Stefan 

                         Reply  Thu Jul 4 10:01:06 2013, tmiron alon, add an average ability to the Scope 

Stefan Ritt wrote:

tmiron alon wrote:

 

My problem is not with wxWidgets itself but with links your program is doing to the wxWidgets. if you can please tell me the wxWidget version you used, I'll use this one instead the version I'm using and I think it will solve the problem.

Tmiron.

I currently use version 2.9.4, but chances are high that it will work with 2.8.12.

/Stefan 

 but was version 2.9.4 the one you used when you built  Version 4.0.0 of the DRS4 oscilloscope program, or was it an erilar version, and if so, do you remeber what version it was?

tmiron.

                            Reply  Thu Jul 4 10:14:32 2013, Stefan Ritt, add an average ability to the Scope 

tmiron alon wrote:

Stefan Ritt wrote:

tmiron alon wrote:

 

My problem is not with wxWidgets itself but with links your program is doing to the wxWidgets. if you can please tell me the wxWidget version you used, I'll use this one instead the version I'm using and I think it will solve the problem.

Tmiron.

I currently use version 2.9.4, but chances are high that it will work with 2.8.12.

/Stefan 

 but was version 2.9.4 the one you used when you built  Version 4.0.0 of the DRS4 oscilloscope program, or was it an erilar version, and if so, do you remeber what version it was?

tmiron.

I used 2.8.12 for Version 4.0.0.

/Stefan 

                               Reply  Tue Jul 16 10:02:28 2013, tmiron alon, add an average ability to the Scope 

Stefan Ritt wrote:

tmiron alon wrote:

Stefan Ritt wrote:

tmiron alon wrote:

 

My problem is not with wxWidgets itself but with links your program is doing to the wxWidgets. if you can please tell me the wxWidget version you used, I'll use this one instead the version I'm using and I think it will solve the problem.

Tmiron.

I currently use version 2.9.4, but chances are high that it will work with 2.8.12.

/Stefan 

 but was version 2.9.4 the one you used when you built  Version 4.0.0 of the DRS4 oscilloscope program, or was it an erilar version, and if so, do you remeber what version it was?

tmiron.

I used 2.8.12 for Version 4.0.0.

/Stefan 

 Hi Stefan.

I managed to add the averaging possibility to the oscilloscope program, but it runs too slow, so now I'm tring to add this option to the example file you attached to the program (drs_exam.cpp).
My problem is that when I run the file is not passing  the stage of getting the trigger. (it just wait after writing the line "Waiting for trigger...")
When testing the software, I work with a signal of up to 10 MHz, limited in voltage to the DRS Eval 4 ability, and I connect the signal to channel 1,from it by default is supposed to get the trigger. I also tried to change the channel settings to other channels or external trigger, and use them,  but it still not working.

I found out that the problem is related to the line "while (b->IsBusy());" in the code, but I have a problem understanding what the function "IsBusy" do and how it's work.

Can you please explain me a bit what this function does?

have a nice day,

Tmiron

                                  Reply  Tue Jul 16 16:25:43 2013, Stefan Ritt, add an average ability to the Scope 

tmiron alon wrote:

Hi Stefan.

I managed to add the averaging possibility to the oscilloscope program, but it runs too slow, so now I'm tring to add this option to the example file you attached to the program (drs_exam.cpp).
My problem is that when I run the file is not passing  the stage of getting the trigger. (it just wait after writing the line "Waiting for trigger...")
When testing the software, I work with a signal of up to 10 MHz, limited in voltage to the DRS Eval 4 ability, and I connect the signal to channel 1,from it by default is supposed to get the trigger. I also tried to change the channel settings to other channels or external trigger, and use them,  but it still not working.

I found out that the problem is related to the line "while (b->IsBusy());" in the code, but I have a problem understanding what the function "IsBusy" do and how it's work.

Can you please explain me a bit what this function does?

have a nice day,

Tmiron

The function b->IsBusy() returns true if there has been no trigger. So "while (b->IsBusy());" is simply an endless loop until the board triggered. Please check your signals and trigger configuration. Maybe you have to adjust the trigger level or polarity via b->SetTriggerLevel(). Try signals with lower event rates. Verify that the board triggers with the DRSOsc program, you can then read off the optimal trigger level from there. 

/Stefan

                                     Reply  Sun Jul 28 09:52:25 2013, tmiron alon, add an average ability to the Scope 

Stefan Ritt wrote:

tmiron alon wrote:

Hi Stefan.

I managed to add the averaging possibility to the oscilloscope program, but it runs too slow, so now I'm tring to add this option to the example file you attached to the program (drs_exam.cpp).
My problem is that when I run the file is not passing  the stage of getting the trigger. (it just wait after writing the line "Waiting for trigger...")
When testing the software, I work with a signal of up to 10 MHz, limited in voltage to the DRS Eval 4 ability, and I connect the signal to channel 1,from it by default is supposed to get the trigger. I also tried to change the channel settings to other channels or external trigger, and use them,  but it still not working.

I found out that the problem is related to the line "while (b->IsBusy());" in the code, but I have a problem understanding what the function "IsBusy" do and how it's work.

Can you please explain me a bit what this function does?

have a nice day,

Tmiron

The function b->IsBusy() returns true if there has been no trigger. So "while (b->IsBusy());" is simply an endless loop until the board triggered. Please check your signals and trigger configuration. Maybe you have to adjust the trigger level or polarity via b->SetTriggerLevel(). Try signals with lower event rates. Verify that the board triggers with the DRSOsc program, you can then read off the optimal trigger level from there. 

/Stefan

Hi satefan,

I did some debug on the DRSOsc program and saw that everywhere you used the function "IsBusy()", you used it with "SoftTrigger()", which (to my understanding) create a software trigger. did you used another function, other than "ISBusy", that check the hardware trigger?

have a nice day,

Tmiron.

                                        Reply  Mon Jul 29 06:04:45 2013, Stefan Ritt, add an average ability to the Scope 

Hi satefan,

I did some debug on the DRSOsc program and saw that everywhere you used the function "IsBusy()", you used it with "SoftTrigger()", which (to my understanding) create a software trigger. did you used another function, other than "ISBusy", that check the hardware trigger?

have a nice day,

Tmiron.

No. IsBusy() is the only way the hardware trigger is checked. If there is no hardware trigger, you can issue a "fake" trigger (called software trigger) to stop the acquisition. This happens for example if you switch DRSOsc to "Auto" trigger instead of "Normal" trigger, very similar than a normal oscilloscope does.

/Stefan 

                                           Reply  Mon Aug 12 15:08:17 2013, tmiron alon, add an average ability to the Scope 

Stefan Ritt wrote:

Hi satefan,

I did some debug on the DRSOsc program and saw that everywhere you used the function "IsBusy()", you used it with "SoftTrigger()", which (to my understanding) create a software trigger. did you used another function, other than "ISBusy", that check the hardware trigger?

have a nice day,

Tmiron.

No. IsBusy() is the only way the hardware trigger is checked. If there is no hardware trigger, you can issue a "fake" trigger (called software trigger) to stop the acquisition. This happens for example if you switch DRSOsc to "Auto" trigger instead of "Normal" trigger, very similar than a normal oscilloscope does.

/Stefan 

 hallo stefan,

I managed to fixed the problem. The problem was with the number I inserted to the function "b->SetTriggerSource" th get external trigger (it suppose to be "16" and not "4" or "12" as I understood from the function's comments).

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?

thanks again,

Tmiron.

                                              Reply  Mon Aug 12 22:18:39 2013, Stefan Ritt, add 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

Entry  Mon Sep 23 09:22:52 2013, Andrzej Rychter, Sampling Frequency: DRS4 eval board 

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

    Reply  Mon Sep 23 09:26:56 2013, Stefan Ritt, Sampling 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 

       Reply  Mon Sep 23 09:51:48 2013, Andrzej Rychter, Sampling Frequency: DRS4 eval board 

Stefan Ritt wrote:

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 

 OK!

Thanks for fast reply.

Andrzej

Entry  Mon Oct 21 14:43:21 2013, Stephane Debieux, DRS4 analog outputs - interfacing DRS4 to AD9222 ADC 

Hi,

I wish to interface the DRS4 with the 8-channel ADC AD9222 (or AD9637).

I'm reading from the DRS4 datasheet that "the analog output of the DRS4 chip has been designed to match directly the input of the AD9222". OUT+ output of DRS4 is in the range from 0.8V to 1.8V and OUT- output is shifted by the voltage applied to the O-OFS pin.

The span of the AD9222 ADC core is defined by REFT and REFB which are resp. 1.4V and 0.4V in a typical case (AVDD=1.8V, VREF=1V). My understanding is that the ADC analog inputs must be within the voltage range defined by REFT and REFB and so I don't quite see how this matches the DRS4 outputs.

Can we use the full-scale range indeed? Do we have to use AC-coupling with mid-supply bias? What is the point I missed?

Thank you for your help.

 

Entry  Tue Aug 27 16:14:49 2013, lengchongyang,  

  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

 

    Reply  Wed Aug 28 04:05:48 2013, lengchongyang,  

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.

       Reply  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.

Entry  Wed Nov 6 11:53:28 2013, Dmitry Hits, flickering screen for drsosc 

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.

    Reply  Wed Nov 6 12:25:31 2013, Stefan Ritt, flickering 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? 

       Reply  Mon Nov 18 11:20:15 2013, Dmitry Hits, flickering screen for drsosc 

Stefan Ritt wrote:

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? 

yes the problem was in wxWidgets, I have downgraded the ubuntu version and installed packaged version of wxWidgets. Now it works without problems.

Thank you,

Dmitry. 

Entry  Tue Nov 19 04:33:22 2013, Andriy Zatserklyaniy, DRSOsc at Mac OS X Mavericks 

 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). 

When I ran from the command line, I see these messages:

phone$ /Applications/DRSOsc.app/Contents/MacOS/DRSOsc

2013-11-18 15:11:31.278 DRSOsc[96539: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-18 15:11:31.279 DRSOsc[96539:507] CoreText performance note: Set a breakpoint on CTFontLogSuboptimalRequest to debug.

2013-11-18 15:11:31.281 DRSOsc[96539: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-18 15:11:31.283 DRSOsc[96539: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-18 15:11:31.285 DRSOsc[96539: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.

0 - 0.250

1 - 0.250

2 - 0.250

3 - 0.250

0 - 0.250

1 - 0.250

2 - 0.250

3 - 0.250

2013-11-18 15:11:32.933 DRSOsc[96539: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.

...

...

 

and these:

 

musb_write: requested 10, wrote 0, errno -4 (Unknown error: -4)

musb_read error 0

musb_write: requested 10, wrote 0, errno -4 (Unknown error: -4)

musb_read error 0

...

...

 

I tried to compile Linux package, but got error messages:

 

drs-4.0.1$ make

cc -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/opt/local/include -DOS_DARWIN -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -c src/musbstd.c

cc -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/opt/local/include -DOS_DARWIN -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -c src/mxml.c

In file included from src/mxml.c:79:

include/strlcpy.h:27:14: error: expected parameter declarator

size_t EXPRT strlcpy(char *dst, const char *src, size_t size);

             ^

/usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'

  __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))

                                           ^

/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                                                             ^

/usr/include/secure/_common.h:30:32: note: expanded from macro '_USE_FORTIFY_LEVEL'

#    define _USE_FORTIFY_LEVEL 2

                               ^

In file included from src/mxml.c:79:

include/strlcpy.h:27:14: error: expected ')'

/usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'

  __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))

                                           ^

/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                                                             ^

/usr/include/secure/_common.h:30:32: note: expanded from macro '_USE_FORTIFY_LEVEL'

#    define _USE_FORTIFY_LEVEL 2

                               ^

include/strlcpy.h:27:14: note: to match this '('

/usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'

  __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))

                                           ^

/usr/include/secure/_common.h:39:53: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                                                    ^

In file included from src/mxml.c:79:

include/strlcpy.h:27:14: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]

size_t EXPRT strlcpy(char *dst, const char *src, size_t size);

             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

/usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'

  __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))

                                           ^~~~~~~~~~~~~~~~~~~~

/usr/include/secure/_common.h:39:31: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                              ^~~~~~~~~~~~~~~~~~~~~

In file included from src/mxml.c:79:

include/strlcpy.h:27:14: error: conflicting types for '__builtin___strlcpy_chk'

/usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'

  __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))

  ^

include/strlcpy.h:27:14: note: '__builtin___strlcpy_chk' is a builtin with type 'unsigned long (char *, const char *, unsigned long, unsigned long)'

/usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'

  __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))

  ^

In file included from src/mxml.c:79:

include/strlcpy.h:28:14: error: expected parameter declarator

size_t EXPRT strlcat(char *dst, const char *src, size_t size);

             ^

/usr/include/secure/_string.h:111:44: note: expanded from macro 'strlcat'

  __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))

                                           ^

/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                                                             ^

/usr/include/secure/_common.h:30:32: note: expanded from macro '_USE_FORTIFY_LEVEL'

#    define _USE_FORTIFY_LEVEL 2

                               ^

In file included from src/mxml.c:79:

include/strlcpy.h:28:14: error: expected ')'

/usr/include/secure/_string.h:111:44: note: expanded from macro 'strlcat'

  __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))

                                           ^

/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                                                             ^

/usr/include/secure/_common.h:30:32: note: expanded from macro '_USE_FORTIFY_LEVEL'

#    define _USE_FORTIFY_LEVEL 2

                               ^

include/strlcpy.h:28:14: note: to match this '('

/usr/include/secure/_string.h:111:44: note: expanded from macro 'strlcat'

  __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))

                                           ^

/usr/include/secure/_common.h:39:53: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                                                    ^

In file included from src/mxml.c:79:

include/strlcpy.h:28:14: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]

size_t EXPRT strlcat(char *dst, const char *src, size_t size);

             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

/usr/include/secure/_string.h:111:44: note: expanded from macro 'strlcat'

  __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))

                                           ^~~~~~~~~~~~~~~~~~~~

/usr/include/secure/_common.h:39:31: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                              ^~~~~~~~~~~~~~~~~~~~~

In file included from src/mxml.c:79:

include/strlcpy.h:28:14: error: conflicting types for '__builtin___strlcat_chk'

/usr/include/secure/_string.h:111:3: note: expanded from macro 'strlcat'

  __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))

  ^

include/strlcpy.h:28:14: note: '__builtin___strlcat_chk' is a builtin with type 'unsigned long (char *, const char *, unsigned long, unsigned long)'

/usr/include/secure/_string.h:111:3: note: expanded from macro 'strlcat'

  __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))

  ^

2 warnings and 6 errors generated.

make: *** [mxml.o] Error 1

 

 

What the best way to build DRSOsc on the Mac OS X?

 

Thanks,

Andriy.

    Reply  Tue Nov 19 09:09:01 2013, Stefan Ritt, DRSOsc 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 

       Reply  Tue Nov 19 21:49:37 2013, Andriy Zatserklyaniy, DRSOsc at Mac OS X Mavericks 

Stefan Ritt wrote:

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 

 I will have beam test next week :-(

I installed wxWidgets-3.0 using MacPorts (and libusb too). After removing strlcpy and hacking of Makefile I managed to build MacOS application. 

 

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.

...

How may I get rid of them?

 

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?

Thanks,

Andriy.

          Reply  Wed Nov 20 08:16:10 2013, Stefan Ritt, DRSOsc 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

 

Entry  Thu Nov 14 11:39:06 2013, Schablo, Cascading of channels  

 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 

    Reply  Thu Nov 14 12:51:56 2013, Stefan Ritt, Cascading of channels  2048_mode.pdf

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 

       Reply  Thu Nov 21 14:35:57 2013, Schablo, Cascading of channels  

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 

 

          Reply  Thu Nov 21 14:45:56 2013, Stefan Ritt, Cascading 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. 

Entry  Tue Nov 26 15:36:39 2013, Dmitry Hits, reducing 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 

    Reply  Tue Nov 26 15:38:13 2013, Stefan Ritt, reducing 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

Entry  Tue Dec 10 14:48:42 2013, ismail okan atakisi, measurement range 

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.  

    Reply  Tue Dec 10 14:54:46 2013, Stefan Ritt, measurement 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

Entry  Fri Dec 13 10:37:18 2013, Dmitry Hits, input protection in DRS4 evaluation board 

 Dear Stefan

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.

Thank you

Dmitry. 

    Reply  Fri Dec 13 11:37:58 2013, Stefan Ritt, input 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

Entry  Mon Nov 18 15:49:01 2013, Dmitry Hits, synchronisation 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.

    Reply  Mon Nov 18 16:00:26 2013, Stefan Ritt, synchronisation 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

       Reply  Mon Dec 16 11:09:25 2013, Dmitry Hits, synchronisation 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

 

 

          Reply  Tue Dec 17 08:45:32 2013, Stefan Ritt, synchronisation 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 

Entry  Thu Jan 9 10:58:19 2014, Martin Petriska, v5 software with v4 board calibration 

 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

    Reply  Thu Jan 9 11:02:46 2014, Stefan Ritt, v5 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

Entry  Tue Sep 10 10:31:30 2013, Akira Okumura, USB connection stops drs_simple.cpp
Hello the DRS4 team,

I and some of my colleagues are using DRS4 evaluation boards (ver. 3) for the R&D of the Cherenkov Telescope Array project. During 
our PMT measurements, we have encountered a problem which is probably related to USB connection. In fact, I cannot reproduce this 
problem with my Linux virtual machine (Scientific Linux 5 64 bit), but other colleagues from three different universities in Japan 
reported the same problem with their real machines.

=== Short Summary ===
DRSBoard::SetFrequency occasionally stops

=== Environment ===
- drs-3.0.0
- Scientific Linux 5.5 (32 bit)
- lib-usb-devel-0.1.12-5.1.i386

=== Steps to Reproduce the Problem ===
1. Compile the attached file drs_simple.cpp with drs-3.0.0
2. Repeat the following command several times from a terminal

$ drs_simple -0.05 1000 ./outputfilename.dat true 2.

3. The above command may stop. In that case, you need to kill the command by Ctrl-C.

=== Comments ===
- Once the command stops, we cannot run the above command properly.
- If we unplug and plug the USB cable again, the command can be executed again.
- It seems that the program stops inside DRSBoard::SetFrequency

I would very appreciate it if you could give me any advise. If you need further information, please let me know.

Akira
    Reply  Wed Sep 11 02:41:28 2013, Andrey Kuznetsov, USB connection stops 
Hi,

although I don't have a chance to test your code, it looks very similar to what I am using.

I can confirm that the DRS4 communication breaks down if the program talking to the DRS4 is closed abruptly or before is has a chance 
to properly execute "delete drs" where it closes the USB connection.

For me if I terminate the program that's using DRS4, the next time I might or might not be able to connect to the DRS4 because I would 
get a magic number or the program would just stop. The DRS4 eval board needs to be restarted via pulling the plug if the orange LED is 
not ON.

I have tried to power down the DRS4 board via software under SL6 linux, but the reality is that the DRS4 eval board is powered directly 
by the 5V USB rail off the computer, and you cannot software control that, you can only suspend the communication of the USB 
port/device.

So I don't have a solution to fix this issue, but my best advice is to change your software such that it calls "delete drs" to 
terminate the USB connection before you close or terminate the program.

Oh and I have not tried running multiple programs at the same time to see if that might be causing the issue as well. The usb library 
might simply error out saying the device is inaccessible because it's being used.

> Hello the DRS4 team,
> 
> I and some of my colleagues are using DRS4 evaluation boards (ver. 3) for the R&D of the Cherenkov Telescope Array project. During 
> our PMT measurements, we have encountered a problem which is probably related to USB connection. In fact, I cannot reproduce this 
> problem with my Linux virtual machine (Scientific Linux 5 64 bit), but other colleagues from three different universities in Japan 
> reported the same problem with their real machines.
> 
> === Short Summary ===
> DRSBoard::SetFrequency occasionally stops
> 
> === Environment ===
> - drs-3.0.0
> - Scientific Linux 5.5 (32 bit)
> - lib-usb-devel-0.1.12-5.1.i386
> 
> === Steps to Reproduce the Problem ===
> 1. Compile the attached file drs_simple.cpp with drs-3.0.0
> 2. Repeat the following command several times from a terminal
> 
> $ drs_simple -0.05 1000 ./outputfilename.dat true 2.
> 
> 3. The above command may stop. In that case, you need to kill the command by Ctrl-C.
> 
> === Comments ===
> - Once the command stops, we cannot run the above command properly.
> - If we unplug and plug the USB cable again, the command can be executed again.
> - It seems that the program stops inside DRSBoard::SetFrequency
> 
> I would very appreciate it if you could give me any advise. If you need further information, please let me know.
> 
> Akira
       Reply  Wed Sep 25 14:42:00 2013, Akira Okumura, USB connection stops 
Hello Andrey,

Thank you for your advise. But we never terminated the program before closing and deleting the DRS object. What we did was just executing the program multiple times 
repeatedly.

Akira
    Reply  Wed Jan 15 15:48:55 2014, Stefan Ritt, USB 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
Entry  Wed Aug 28 13:07:51 2013, Andrey Kuznetsov, Some bug fixes and questions 

  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 ?

 I've been reviewing DRS.cpp v4.0.1

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


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.


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?

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.

 

I'll post more if I have any questions or spot any more bugs.

    Reply  Thu Sep 5 10:01:00 2013, Andrey Kuznetsov, Some bug fixes and questions 

#11 0x080589de in DRSBoard::GetWave (this=0xb7456008, chipIndex=0, channel=0 '\000', waveform=0x40f24000, responseCalib=true, triggerCell=207, wsr=0, adjustToClock=false, threshold=1, offsetCalib=true) at src/DRS.cpp:3380

This is calling:

int GetWave(unsigned int chipIndex, unsigned char channel, float *waveform, bool responseCalib, int triggerCell = -1, int wsr = -1, bool adjustToClock = false, float threshold = 0, bool offsetCalib = true);

from DRS.cpp:
return GetWave(chipIndex, channel, waveform, true, fStopCell[chipIndex], false, 0, true);

false=0
true=1

As you can see offsetCalib ends up being defined by default, threshold set to 1 because of true, adjustToClock is false set by 0, wsr is 0 set by false, however threshold is never used with DRS4 eval board. 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.

       Reply  Mon Sep 9 06:49:36 2013, Andrey Kuznetsov, Some bug fixes and questions 

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.

          Reply  Wed Jan 15 17:11:14 2014, Stefan Ritt, Some 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. 

       Reply  Wed Jan 15 17:02:58 2014, Stefan Ritt, Some 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. 

    Reply  Wed Jan 15 16:15:00 2014, Stefan Ritt, Some 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.

Entry  Wed May 8 06:07:52 2013, Andrey Kuznetsov, DRS4 v2.0 Eval Board running on higher versions of DRS Oscilloscope program 

Hi,

I have an old v2.0 board that I just upgraded firmware on using v4.0.0 download package which has a drs4_eval1.bit for v2.0 boards containing firmware 15158. So I would like to use the latest DRS Oscilloscope program, due to the faster acquisition speeds and advanced calibration techniques, however I seem to be running into a problem.

v4.0 DRS Oscilloscope program displays flat lines in any configuration instead of a pulse that I provide to it (I can't tell if calibration works because all my traces are flat and nothing triggers) but provides ~460Hz. Any idea why v4.0.0 DRS Oscilloscope program does not work with DRS4 Eval Board v2.0 fw:15158?

 

v3.0 DRS Oscilloscope program actually works and displays the pulse that I input (calibration also works), however it only has 64Hz speed due to v3.0.0 not having multithreading capability which is provided in v3.1.0 software version of the program.

 

Can you please upload and post on the website the latest software packages for v2 and v3? I would like to use v3.1.0 DRS Oscilloscope version. (Both Linux and Windows, but Linux preferably)

 

Also, I would like to report that for some reason, I don't know if it happens with v3.0 program used on v2.0 board only or a general issue, but after each calibration of voltage and timing, the trigger does not work. I have to exit the oscilloscope program, and run it again, then the trigger works fine, and the device is calibrated.

Thank you

    Reply  Wed May 8 19:50:01 2013, Andrey Kuznetsov, DRS4 installation on Windows 8 issues 

I'm also having trouble installing drivers and running DRSOsc program on another computer running Windows 8.


The issue with the driver is that it's not digitally signed.


The issue with the DRSOsc is that it's failing to find libusb0.dll. libusb-win32 seemed to have installed upon DRS4 software install, however the supplied version is Windows 7/8 incompatible, so on Windows 7 computer I had to download libusb_win32 v1.2.6.0 from the official website and install it directly, then everything worked fine. However in Windows 8, I am unable to install libusb-win32 because in  libusb-win32 Inf Wizard installation program when you select for which device the libusb should be used, it asks to install a driver, but when I point to DRS' driver, it says "Unknown Error: 1" and that's that. One way around the libusb issue is to copy the required dll and sys file directly where the .exe is stored.


I will attempt to disable signed driver signature requirement, and see if the driver installs then, but this should really be fixed instead.

       Reply  Wed Jan 15 17:37:21 2014, Stefan Ritt, DRS4 installation on Windows 8 issues 

Andrey Kuznetsov wrote:

I'm also having trouble installing drivers and running DRSOsc program on another computer running Windows 8.


The issue with the driver is that it's not digitally signed.


The issue with the DRSOsc is that it's failing to find libusb0.dll. libusb-win32 seemed to have installed upon DRS4 software install, however the supplied version is Windows 7/8 incompatible, so on Windows 7 computer I had to download libusb_win32 v1.2.6.0 from the official website and install it directly, then everything worked fine. However in Windows 8, I am unable to install libusb-win32 because in  libusb-win32 Inf Wizard installation program when you select for which device the libusb should be used, it asks to install a driver, but when I point to DRS' driver, it says "Unknown Error: 1" and that's that. One way around the libusb issue is to copy the required dll and sys file directly where the .exe is stored.


I will attempt to disable signed driver signature requirement, and see if the driver installs then, but this should really be fixed instead.

Did you have any progress with that? Unfortunately I don't have a Windows 8 machine here at our institute, so I cannot reproduce your problem. At least I put the 1.2.6 libusb driver into the V5 software package. 

    Reply  Wed Jan 15 17:34:55 2014, Stefan Ritt, DRS4 v2.0 Eval Board running on higher versions of DRS Oscilloscope program 

Andrey Kuznetsov wrote:

Hi,

I have an old v2.0 board that I just upgraded firmware on using v4.0.0 download package which has a drs4_eval1.bit for v2.0 boards containing firmware 15158. So I would like to use the latest DRS Oscilloscope program, due to the faster acquisition speeds and advanced calibration techniques, however I seem to be running into a problem.

v4.0 DRS Oscilloscope program displays flat lines in any configuration instead of a pulse that I provide to it (I can't tell if calibration works because all my traces are flat and nothing triggers) but provides ~460Hz. Any idea why v4.0.0 DRS Oscilloscope program does not work with DRS4 Eval Board v2.0 fw:15158?

 

v3.0 DRS Oscilloscope program actually works and displays the pulse that I input (calibration also works), however it only has 64Hz speed due to v3.0.0 not having multithreading capability which is provided in v3.1.0 software version of the program.

 

Can you please upload and post on the website the latest software packages for v2 and v3? I would like to use v3.1.0 DRS Oscilloscope version. (Both Linux and Windows, but Linux preferably)

 

Also, I would like to report that for some reason, I don't know if it happens with v3.0 program used on v2.0 board only or a general issue, but after each calibration of voltage and timing, the trigger does not work. I have to exit the oscilloscope program, and run it again, then the trigger works fine, and the device is calibrated.

Thank you

Unfortunately I do not have the time to back-port any new software feature to the old V2 and V3 boards. That means you have to live with their software or try to get a new board. Right now we have the V5 board which allows you 1 ps time measurements. Maybe this is a good argument to upgrade the hardware.

/Stefan 

Entry  Wed Aug 7 15:05:59 2013, Hermann-Josef Mathes, Repeated time calibration 

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

 

    Reply  Wed Aug 7 15:10:57 2013, Stefan Ritt, Repeated 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

 

       Reply  Wed Aug 7 15:20:33 2013, Hermann-Josef Mathes, Repeated time calibration 

Stefan Ritt wrote:

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

 

 Hi Stefan,

thanks for the quick reply, I know that this solution works with drscl but not within my code.

I tried to track it down, but gave up very soon. Seems as if AnalyzeWF() which is called by CalibrateTiming() finds to much zero-crossings when it is called the second time.

Regards

  -- Hermann-Josef

          Reply  Wed Feb 5 13:41:42 2014, Stefan Ritt, Repeated time calibration 

Hermann-Josef Mathes wrote:

Hi Stefan,

thanks for the quick reply, I know that this solution works with drscl but not within my code.

I tried to track it down, but gave up very soon. Seems as if AnalyzeWF() which is called by CalibrateTiming() finds to much zero-crossings when it is called the second time.

Regards

  -- Hermann-Josef

Time calibration has been changed completely in meantime. With the new V5 boards, we have a new oscillator on the board where on can calibrate each channel individually. This is necessary to obtain a good timing down to a few ps. With the current code the above problem has vanished. We also learned that the time calibration is very stable (less than a ps) over several months, so no need to repeat the calibration over and over again.

/Stefan 

Entry  Wed Mar 5 21:54:13 2014, Hermann-Josef Mathes, Software drs-5.0.0 fails to compile (drsosc) drs-5.patch

Hi,

the latest software drs-5.0.0.tar.gz fails to compile on my freshly installed SuSE 13.1 whereas the previous 4.0.1 is compiling out-of-the-box.

My system has the wxWidgets 2.8.12 which is probably together with gcc 4.8.1 the reason of the problem. I applied a number of corrections, mainly some sort of proper (?) typecasts, a patch file is attached.

Maybe you could consider to take them into account for the next patch release?

Thanks and best regards

Hermann-Josef

 

    Reply  Thu Mar 6 11:12:44 2014, Stefan Ritt, Software drs-5.0.0 fails to compile (drsosc) 

Hermann-Josef Mathes wrote:

Hi,

the latest software drs-5.0.0.tar.gz fails to compile on my freshly installed SuSE 13.1 whereas the previous 4.0.1 is compiling out-of-the-box.

My system has the wxWidgets 2.8.12 which is probably together with gcc 4.8.1 the reason of the problem. I applied a number of corrections, mainly some sort of proper (?) typecasts, a patch file is attached.

Maybe you could consider to take them into account for the next patch release?

Thanks and best regards

Hermann-Josef

Thank you very much for the corrections. I know it in principle, but neither my Mac OSX nor the Windows compiler complains, so I usually don't see this errors. It's fixed now.

/Stefan 

Entry  Wed Apr 16 03:22:43 2014, Wang , why is the first channel output error?  QQ??20140416090124.jpg

 Hi,

 The diagram below is DRS4 output. Green is the output8+, blue is the output8-. Output8+ of the first channel is below  the baseline. It is not  right.

Others channel  is suitable. I check the circuit , Hardware is no problem, so I want to konw where the FPGA code  is wrong. what reason is caused? Thanks!

    Reply  Wed Apr 16 08:30:32 2014, Stefan Ritt, why is the first channel output error?  

Wang wrote:

 Hi,

 The diagram below is DRS4 output. Green is the output8+, blue is the output8-. Output8+ of the first channel is below  the baseline. It is not  right.

Others channel  is suitable. I check the circuit , Hardware is no problem, so I want to konw where the FPGA code  is wrong. what reason is caused? Thanks!

You are funny. Just by looking at a scope picture I should know what is wrong at your FPGA code. Unfortunately I'm not a magician. I looks to me like you have 11 channels in your diagram, although the chip has only 9. What I would recommend is to put some input to each channel one at a time, like a 10 MHz sine wave. You should then see that sine wave for the single channel at the output and can correlate input vs. output. Maybe your address bits are wrong or the chip has a soldering problem.

/Stefan 

Entry  Thu Apr 10 14:45:12 2014, Roman Gredig, DRS4 Evalboard V5 with Windows7Pro64bit 
Dear Stefan

I am trying to use the DRS4 eval board on a Windows7 machine. Unfortunately I get an error message saying "No DRS 
board found". But I can see the DRS board in the device manager with the proper driver loaded. Is there any known 
problem with win7?

I am using windows7 professional (SP1) with the drs software 5.0.1.

Cheers,
Roman

PS: Everything is working on my mac. But not under windows7.
    Reply  Wed Apr 16 10:24:55 2014, Stefan Ritt, DRS4 Evalboard V5 with Windows7Pro64bit 
> 
> Dear Stefan
> 
> I am trying to use the DRS4 eval board on a Windows7 machine. Unfortunately I get an error message saying "No DRS 
> board found". But I can see the DRS board in the device manager with the proper driver loaded. Is there any known 
> problem with win7?
> 
> I am using windows7 professional (SP1) with the drs software 5.0.1.
> 
> Cheers,
> Roman
> 
> PS: Everything is working on my mac. But not under windows7.

Hi Roman,

please read section 2.3. (page 13)  from the Evaluation Board manual: http://www.psi.ch/drs/DocumentationEN/manual_rev50.pdf

You have to update the USB driver in your Computer Management.

Cheers,
Stefan 
Entry  Thu Apr 17 12:02:28 2014, Wang , The first channel is wrong. QQ??20140417174309.jpg

 Hi,

   I want to describe this phenomenon again. The diagram below is DRS4 output. There is no input signal. Green is the output8+, blue is the output8-. Output8+ of the first channel is below  the baseline. The output is saturation when input ADC. It is not right, and what is it  in front of the first channel? It seemed there are two channels.  Others channel  is suitable. I check the circuit , Hardware is no problem, so I want to konw where the FPGA code  is wrong. What reason is caused? Can anyone help me to solve the problem? Thanks!

Entry  Tue Apr 15 18:35:41 2014, Carlo Stella, drs_exam project fail to compile 

Hi,

when I try to compile drs_exam project my computer give me this output:

 

1>------ Rebuild All started: Project: drs_exam, Configuration: Debug Win32 ------
1>  averager.cpp
1>c:\users\daq\desktop\

original drs\drs5\src\averager.cpp(165): warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1>          c:\program files (x86)\microsoft visual studio 10.0\vc\include\stdio.h(234) : see declaration of 'fopen'
1>  DRS.cpp
1>c:\users\daq\desktop\original drs\drs5\src\drs.cpp(4597): warning C4244: '=' : conversion from 'double' to 'float', possible loss of data
1>  drs_exam.cpp
1>  Generating Code...
1>  musbstd.c
1>  mxml.c
1>  strlcpy.c
1>  Generating Code...
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_claim_interface referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_set_configuration referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_open referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_get_busses referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_set_debug referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_find_devices referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_find_busses referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_init referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_set_altinterface referenced in function _musb_set_altinterface
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_close referenced in function _musb_close
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_release_interface referenced in function _musb_close
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_bulk_write referenced in function _musb_write
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_bulk_read referenced in function _musb_read
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_reset referenced in function _musb_reset
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_get_descriptor referenced in function _musb_get_device
1>.\Debug/drs_exam.exe : fatal error LNK1120: 15 unresolved externals
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
 
Can anyone help me to solve the problem?
    Reply  Wed Apr 16 08:20:36 2014, Stefan Ritt, drs_exam project fail to compile 

Carlo Stella wrote:

Hi,

when I try to compile drs_exam project my computer give me this output:

 

1>------ Rebuild All started: Project: drs_exam, Configuration: Debug Win32 ------
1>  averager.cpp
1>c:\users\daq\desktop\

original drs\drs5\src\averager.cpp(165): warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1>          c:\program files (x86)\microsoft visual studio 10.0\vc\include\stdio.h(234) : see declaration of 'fopen'
1>  DRS.cpp
1>c:\users\daq\desktop\original drs\drs5\src\drs.cpp(4597): warning C4244: '=' : conversion from 'double' to 'float', possible loss of data
1>  drs_exam.cpp
1>  Generating Code...
1>  musbstd.c
1>  mxml.c
1>  strlcpy.c
1>  Generating Code...
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_claim_interface referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_set_configuration referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_open referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_get_busses referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_set_debug referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_find_devices referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_find_busses referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_init referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_set_altinterface referenced in function _musb_set_altinterface
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_close referenced in function _musb_close
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_release_interface referenced in function _musb_close
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_bulk_write referenced in function _musb_write
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_bulk_read referenced in function _musb_read
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_reset referenced in function _musb_reset
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_get_descriptor referenced in function _musb_get_device
1>.\Debug/drs_exam.exe : fatal error LNK1120: 15 unresolved externals
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
 
Can anyone help me to solve the problem?

Have a look at the web site http://www.psi.ch/drs/software-download . Under the MS Windows section it says that you have to install the libusb-1.0 package first before you can compile the example program. This is also obvious from the missing _usb_* functions in the error listing above.

/Stefan

       Reply  Thu Apr 24 23:03:25 2014, Carlo Stella, drs_exam project fail to compile 

Stefan Ritt wrote:

Carlo Stella wrote:

Hi,

when I try to compile drs_exam project my computer give me this output:

 

1>------ Rebuild All started: Project: drs_exam, Configuration: Debug Win32 ------
1>  averager.cpp
1>c:\users\daq\desktop\

original drs\drs5\src\averager.cpp(165): warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1>          c:\program files (x86)\microsoft visual studio 10.0\vc\include\stdio.h(234) : see declaration of 'fopen'
1>  DRS.cpp
1>c:\users\daq\desktop\original drs\drs5\src\drs.cpp(4597): warning C4244: '=' : conversion from 'double' to 'float', possible loss of data
1>  drs_exam.cpp
1>  Generating Code...
1>  musbstd.c
1>  mxml.c
1>  strlcpy.c
1>  Generating Code...
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_claim_interface referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_set_configuration referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_open referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_get_busses referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_set_debug referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_find_devices referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_find_busses referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_init referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_set_altinterface referenced in function _musb_set_altinterface
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_close referenced in function _musb_close
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_release_interface referenced in function _musb_close
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_bulk_write referenced in function _musb_write
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_bulk_read referenced in function _musb_read
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_reset referenced in function _musb_reset
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_get_descriptor referenced in function _musb_get_device
1>.\Debug/drs_exam.exe : fatal error LNK1120: 15 unresolved externals
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
 
Can anyone help me to solve the problem?

Have a look at the web site http://www.psi.ch/drs/software-download . Under the MS Windows section it says that you have to install the libusb-1.0 package first before you can compile the example program. This is also obvious from the missing _usb_* functions in the error listing above.

/Stefan

 Hi Stefan,

you were right, I forgot to install the libusb driver.

Thanks for your support

Entry  Fri May 16 14:04:47 2014, Benjamin LeGeyt, simultaneous 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

    Reply  Mon May 19 08:04:57 2014, Stefan Ritt, simultaneous 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 

Entry  Tue May 27 13:46:18 2014, Dominik Neise, Spikes in DRS4 data on custom baord. 

We see quite some spikes in our DRS4 sampled data in FACT.  We see different types of spikes:

  • single cell spikes, usually showing a large amplitude of 200mV
  • double cell spikes, usually only in the order of 20mV.
  • Even triple and quadro cell spikes are rarely seen.

The double cell spikes often occur as symmetrical double cell spikes mirrored at cell 512. quadro cell spikes seem to be nothing else, than connected symmetrical double cell spikes. For the triple cell spikes we have no idea.
Currently we use simple filters to get rid of these spikes, this workes rather well for the large single cell spikes, but with the occurance of tripples and quadros we started to worry about higher multiples and revived our DRS4 spike investigations.

Now I was told, that you Stefan know already where these spikes come from and even a paper exisits. Unfortunately so far I was unable to find it.
I wonder if it is possible to predict the occurance of these spikes, so one does not have to search for them anymore and can get rid of the filters.

Best regards

Dominik

    Reply  Tue May 27 16:07:17 2014, Stefan Ritt, Spikes in DRS4 data on custom baord. 

Dominik Neise wrote:

We see quite some spikes in our DRS4 sampled data in FACT.  We see different types of spikes:

  • single cell spikes, usually showing a large amplitude of 200mV
  • double cell spikes, usually only in the order of 20mV.
  • Even triple and quadro cell spikes are rarely seen.

The double cell spikes often occur as symmetrical double cell spikes mirrored at cell 512. quadro cell spikes seem to be nothing else, than connected symmetrical double cell spikes. For the triple cell spikes we have no idea.
Currently we use simple filters to get rid of these spikes, this workes rather well for the large single cell spikes, but with the occurance of tripples and quadros we started to worry about higher multiples and revived our DRS4 spike investigations.

Now I was told, that you Stefan know already where these spikes come from and even a paper exisits. Unfortunately so far I was unable to find it.
I wonder if it is possible to predict the occurance of these spikes, so one does not have to search for them anymore and can get rid of the filters.

Best regards

Dominik

All I know is that the  "20mV" spikes are always symmetrical around cell #512, that they are typically 17.4 mV in height, and that they occur always in all 9 channels simultaneously. They cannot occur in all locations, but there only like 32 possible locations where they can occur. With this information it should be easy to fix them by filtering.

200 mV spikes are new to me. I do not see them in our boards, so it must be related to the board readout and not to the chip.

Best regards,
Stefan
 

Entry  Thu Jun 12 12:40:03 2014, Roman Gredig, DRS eval bord v5 Timing eqn1.png
Dear Stefan

I have two questions concerning the best time resolution with the DRS V5 eval board.
a) Calibration:
I am using 4 boards daisy chained. To achieve optimal time resolution I did first a voltage calibration and right afterwards a time calibration. For all 
boards after the master I am not sure how to do it.
After setting the flag "Configure multi-board daisy-chain" in the config menu, all the slave boards set the flag "use external reference clock".  By 
hitting the voltage calibration button, the slave boards unset this flag. Is it true, that I have to re-set this before doing the time-calibration right 
afterwards?


b) getting the right times in binary format:
To get the time out of the time width (i.e. the t_ch[i]) you sum up in your documentation from j=0 to j=i (see attachment). In your example code 
read_binary.cpp (line 113) you sum from j=0 to j=i-1. Since you get the the bin with in the binary file, I guess that the example code is correct one?

Thank you very much,
Cheers,
Roman
    Reply  Thu Jun 12 12:46:00 2014, Stefan Ritt, DRS eval bord v5 Timing 
> a) Calibration:
> I am using 4 boards daisy chained. To achieve optimal time resolution I did first a voltage calibration and right afterwards a time calibration. For all 
> boards after the master I am not sure how to do it.
> After setting the flag "Configure multi-board daisy-chain" in the config menu, all the slave boards set the flag "use external reference clock".  By 
> hitting the voltage calibration button, the slave boards unset this flag. Is it true, that I have to re-set this before doing the time-calibration right 
> afterwards?

Please do NOT do any calibration in multi-board mode. This will not work. Calibrate the boards separately, then activate the multi-board mode. Please note that the timing between the boards is not better 
than ~50 ps. This is a limitation of the FPGA clock generators. If you need better timing, you have to feed an external clock into one channel of each board (leaving only 3 channels for DAQ). The upcoming 
WaveDREAM board will have 16 channels per board, so building bigger DAQ systems will be much easier (and more precise).

> b) getting the right times in binary format:
> To get the time out of the time width (i.e. the t_ch[i]) you sum up in your documentation from j=0 to j=i (see attachment). In your example code 
> read_binary.cpp (line 113) you sum from j=0 to j=i-1. Since you get the the bin with in the binary file, I guess that the example code is correct one?

Yes, I will correct the documentation.

Cheers,
Stefan
Entry  Thu May 29 04:22:43 2014, Toshihiro Nonaka, CalibrationWaveform offset.png

I'm writing the drs_exam.cpp to use multi-boards(v3, firmware:4.0.0), and taking data succeeded. But I have several questions about function written in DRS.cpp.

 

  1. I wrote following code in drs_exam.cpp to set input range -0.4~0.6

                                     b1->SetInputRange(0.1);

            And the 100mV offset appeared(I attached a picture). I think this is due to the voltage calibration isn't done.(Calibrated to -0.5~0.5mV in DRS Oscilloscope)

            If so, could you show me a simple usage of "CalibrationWaveform()" function in DRS.cpp? (or other function?)

 

       2. Although this question might be the almost same with above, is there any way to execute voltage and timing calibration in drs_exam.cpp?

           Now I start DAQ by executing drs_exam.cpp after I execute voltage and timing calibration to each board by DRS Oscilloscope program.

 

      3. Which command is right to use external trigger?

                                   b1->SetTriggerSource(4);   or  b1->SetTriggerSource(1<<4);

 

Best regards,

Toshihiro Nonaka

    Reply  Thu Jun 12 17:16:13 2014, Stefan Ritt, CalibrationWaveform 

Toshihiro Nonaka wrote:

I'm writing the drs_exam.cpp to use multi-boards(v3, firmware:4.0.0), and taking data succeeded. But I have several questions about function written in DRS.cpp.

 

  1. I wrote following code in drs_exam.cpp to set input range -0.4~0.6

                                     b1->SetInputRange(0.1);

            And the 100mV offset appeared(I attached a picture). I think this is due to the voltage calibration isn't done.(Calibrated to -0.5~0.5mV in DRS Oscilloscope)

            If so, could you show me a simple usage of "CalibrationWaveform()" function in DRS.cpp? (or other function?)

 

       2. Although this question might be the almost same with above, is there any way to execute voltage and timing calibration in drs_exam.cpp?

           Now I start DAQ by executing drs_exam.cpp after I execute voltage and timing calibration to each board by DRS Oscilloscope program.

 

      3. Which command is right to use external trigger?

                                   b1->SetTriggerSource(4);   or  b1->SetTriggerSource(1<<4);

 

Best regards,

Toshihiro Nonaka

1. b->CalibrateVolt(NULL);

2. see 1.

3. For the V3 boards use b->SetTriggerSource(4), for V4 and V5 boards, use b->SetTriggerSource(1<<4). I had to change that because from V4 on we can have logical combinations between channels (like channel 1 AND channel 2).

Best regards,

Stefan 

Entry  Wed Jan 15 14:20:51 2014, Stefan Ritt, Announcement of new Evaluation Board V5 drsosc.png

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
 

    Reply  Tue Feb 18 14:12:37 2014, Stefan Ritt, Announcement of new Evaluation Board V5 scope.png

Stefan Ritt wrote:

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).

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
 

The new software for the V5 evaluation board has been released today with following new features:

  • Hardware scalers for all four channels and the trigger working up to 200 MHz. With the trigger scaler one can measure for example coincidence rates between two channels.
  • New vertical and horizontal "slice" measurements. This allows to measure the amplitude of a signal at a certain time relative to the trigger point or the time when a signal crosses a certain level.
  • Gated charge measurement allowing to measure the charge of a signal between two time markers, like an old-fashioned charge integrating ADC.

The software is available at the the usual location http://www.psi.ch/drs/software-download for Linux, Windows and Mac OSX. I'm working right now to get it also into the Apple App Store.

/Stefan

       Reply  Mon Jun 9 12:03:26 2014, Osip Lishilin, Announcement of new Evaluation Board V5 

Stefan Ritt wrote:

Hardware scalers for all four channels and the trigger working up to 200 MHz. With the trigger scaler one can measure for example coincidence rates between two channels.

 Does it give the ability to measure triggering rate? I'm talking again about possibility of use DRS4 as pulse counter for PMT's. If yes, do I need new v5 board or it is possible to use v4 board?

          Reply  Wed Jun 11 11:13:50 2014, Stefan Ritt, Announcement of new Evaluation Board V5 

Osip Lishilin wrote:

Stefan Ritt wrote:

Hardware scalers for all four channels and the trigger working up to 200 MHz. With the trigger scaler one can measure for example coincidence rates between two channels.

 Does it give the ability to measure triggering rate? I'm talking again about possibility of use DRS4 as pulse counter for PMT's. If yes, do I need new v5 board or it is possible to use v4 board?

Yes it is possible to measure the raw trigger rate, with a resolution of 10 Hz. You need a new V5 board for that. 

             Reply  Mon Jun 16 15:35:59 2014, Osip Lishilin, Announcement of new Evaluation Board V5 

Stefan Ritt wrote:

Osip Lishilin wrote:

Stefan Ritt wrote:

Hardware scalers for all four channels and the trigger working up to 200 MHz. With the trigger scaler one can measure for example coincidence rates between two channels.

 Does it give the ability to measure triggering rate? I'm talking again about possibility of use DRS4 as pulse counter for PMT's. If yes, do I need new v5 board or it is possible to use v4 board?

Yes it is possible to measure the raw trigger rate, with a resolution of 10 Hz. You need a new V5 board for that. 

I'm not sure if I understand you correctly. The trigger rate could be up to 200 MHz, and it's possible to measure it  with 10 Hz resolution. Is it right?

Does it possible to measure independent trigger rate for each channel?

Entry  Mon Jul 14 19:03:05 2014, Yves Bianga, change cascading from 1024 to 2048 bins for each input channel 

Hello,

 
I want to ask whether it is possible to modify a Evaluation Board 5.0 from 1024 to 2048 cells for each of the 4 input channels.
On the rev50 manual at page 31 I found an option to connect the 4 unused channels by setting 8 solder bridges.
The source code for controlling the board seems already prepared for 2048 bins, since version 5.0.2.
 
So my first question: Are there any implementations in the VHDL Code to control the write shift register in 2048 mode? / Is there a necessity for a newer/other VHDL Code or is it already implemented?
 
And the second: Are there any other modifications except the eight zero Ohm resistors and maybe changes in the FPGA code?
 
My board info output:
 
Mezz. Board index:    0
DRS type:             DRS4
Board type:           9
Serial number:        2451
Firmware revision:    21260
 
 
Thanks a lot!
 
Yves Bianga
    Reply  Wed Jul 16 12:10:19 2014, Stefan Ritt, change cascading from 1024 to 2048 bins for each input channel 

Yves Bianga wrote:

Hello,

 
I want to ask whether it is possible to modify a Evaluation Board 5.0 from 1024 to 2048 cells for each of the 4 input channels.
On the rev50 manual at page 31 I found an option to connect the 4 unused channels by setting 8 solder bridges.
The source code for controlling the board seems already prepared for 2048 bins, since version 5.0.2.
 
So my first question: Are there any implementations in the VHDL Code to control the write shift register in 2048 mode? / Is there a necessity for a newer/other VHDL Code or is it already implemented?
 
And the second: Are there any other modifications except the eight zero Ohm resistors and maybe changes in the FPGA code?
 
My board info output:
 
Mezz. Board index:    0
DRS type:             DRS4
Board type:           9
Serial number:        2451
Firmware revision:    21260
 
 
Thanks a lot!
 
Yves Bianga

Indeed you only need R99-R106 to be installed. Unfortunately the firm/software cannot know if the resistors are there, that's why we introduced R142/R143, which connect J44 of the FPGA optionally to low. So if J44 is low (R143 installed), this tells the system that we are in 2048 bin mode. Unfortunately you need firmware revision 21305 or later to support this bit, which you apparently do not have. So you can either upgrade the firmware (if you have a download cable) or "fake" the 2048 bin mode in software. Go to line 4345 of DRS.cpp and look for DRSBoard::Is2048ModeCapable(). This function just returns the status of this bit. If you installed R99-R106, you could modify this function to always return "1" instead of "0". Then the DRSOsc program will display 2048 bins for each of the four channels.

Best regards,

Stefan 

Entry  Wed Jul 30 11:38:58 2014, Tsutomu Nagayoshi, Sampling speed of DRS4 Board ver4 

 Hello!

I have a question concerning the sampling speed of the DRS4 evaluation board.

It is written in the manual that the sampling speed of  DRS4 Evaluation Board is supported above 0.7 GHz.

However I was able to set the sampling speed to be 0.5 GHz with the function DRSBpard::SetFrequency(0.5)  and realized that DRSBoard::GetTime function fills time array in every 2 ns.

I am wondering if the data taken with 0.5 GHz sampling is reliable or not.

 

Best regards,

Tsutomu Nagayoshi

 

 

Entry  Tue Jun 18 14:19:39 2013, Stefan Ritt, ROOT program to decode binary data from DRSOsc decode.Cc1.gif

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:
 
c1.gif 

 

/Stefan

    Reply  Wed Jul 30 17:05:06 2014, Stefan Ritt, ROOT program to decode binary data from DRSOsc read_binary.Cread_binary.cpp

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:
 
c1.gif 

 

/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. 

Entry  Tue May 13 19:34:58 2014, Luka Pavelic, drsosc binary to cern ROOT file conversion 

Hi,

Does anybody have program for conversion from binary or xml to cern ROOT *.root file?
 

Thank you for any help you can provide,
Luka Pavelic


 

    Reply  Tue May 13 19:39:36 2014, Stefan Ritt, drsosc binary to cern ROOT file conversion 

Luka Pavelic wrote:

Hi,

Does anybody have program for conversion from binary or xml to cern ROOT *.root file?
 

Thank you for any help you can provide,
Luka Pavelic


 

You look here: elog:262

/Stefan

       Reply  Tue May 13 22:03:47 2014, Luka Pavelic, drsosc binary to cern ROOT file conversion 

Thank you for your fast and very helpful replay.

I made it work with drsosc version 4 but with version 5 i am getting weird results. Is it possible that they changed binary formatting?

 

          Reply  Tue May 13 23:08:50 2014, Stefan Ritt, drsosc binary to cern ROOT file conversion 

Luka Pavelic wrote:

Thank you for your fast and very helpful replay.

I made it work with drsosc version 4 but with version 5 i am getting weird results. Is it possible that they changed binary formatting?

 

Yes, but this is documented in the evaluation board manual. You have to modify the script slightly. I will update it myself in about 2-3 weeks.

Cheers,

Stefan

             Reply  Fri Jun 27 11:23:19 2014, ChengMing Du, drsosc binary to cern ROOT file conversion 

Stefan Ritt wrote:

Luka Pavelic wrote:

Thank you for your fast and very helpful replay.

I made it work with drsosc version 4 but with version 5 i am getting weird results. Is it possible that they changed binary formatting?

 

Yes, but this is documented in the evaluation board manual. You have to modify the script slightly. I will update it myself in about 2-3 weeks.

Cheers,

Stefan

 hi Stefan,can you update the code to convert binary to root for newest drsosc?Thanks.

                Reply  Wed Jul 30 17:05:38 2014, Stefan Ritt, drsosc binary to cern ROOT file conversion 

ChengMing Du wrote:

Stefan Ritt wrote:

Luka Pavelic wrote:

Thank you for your fast and very helpful replay.

I made it work with drsosc version 4 but with version 5 i am getting weird results. Is it possible that they changed binary formatting?

 

Yes, but this is documented in the evaluation board manual. You have to modify the script slightly. I will update it myself in about 2-3 weeks.

Cheers,

Stefan

 hi Stefan,can you update the code to convert binary to root for newest drsosc?Thanks.

See elog:361 

Entry  Thu Aug 21 11:03:36 2014, Martin Petriska, 10GSps on DRS4 Evm with delay cables 

 Hi, I read its possible to use channels 2,4,6 to extend 200ns to 400ns (1024bins to 2048).

Is it possible to use same channels to double sampling rate with paralel feeding, one channel delayed by Ts/2, for 5,12GS/s is it cca 3cm delay cable?

 

Martin

    Reply  Tue Aug 26 12:32:21 2014, Stefan Ritt, 10GSps on DRS4 Evm with delay cables 

Martin Petriska wrote:

 Hi, I read its possible to use channels 2,4,6 to extend 200ns to 400ns (1024bins to 2048).

Is it possible to use same channels to double sampling rate with paralel feeding, one channel delayed by Ts/2, for 5,12GS/s is it cca 3cm delay cable?

 

Martin

In principle yes (you could split your signal externally and add some cable delay to one side), but it is not supported by the software. You would have to combine the data from the two channels yourself. But it won't help much. The analog bandwidth of the evaluation board is about 700 MHz. So sampling at 10 GSPS vs. 5 GSPS won't give you any additional information, since the highest frequencies in your signal will be only 700 MHz. You could as well take your 5 GSPS measurement and interpolate it with some sinc function to get exactly the same result. See here for details: http://en.wikipedia.org/wiki/Whittaker%E2%80%93Shannon_interpolation_formula 

Entry  Fri Sep 12 11:52:21 2014, Dmitry Hits, synchronizing 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.

 

    Reply  Fri Sep 12 13:00:04 2014, Stefan Ritt, synchronizing 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

       Reply  Fri Sep 12 13:37:42 2014, Dmitry Hits, synchronizing 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

          Reply  Fri Sep 12 13:41:43 2014, Stefan Ritt, synchronizing two DRS4 evaluation boards readout with one computer 

Dmitry Hits wrote:

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

In principle it should also work with version 4, but I'm not sure how well the V4 software supports this. You might try the V5 software with your V4 boards.

/Stefan 

Entry  Fri Sep 12 14:57:22 2014, Dmitry Hits, compilation error for v5.0.2 

 Hi,

I am getting the following compilation error when trying to compile version 5.0.2 software:

src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]
 
I have wxWidgets v. 2.8.12 package on Fedora version 3.9.10-100.fc17.x86_64
 
Has anyone seen this before?
 
Thank you,
 
Dmitry 

 

---------------------------------------------------------------------------------------------

Full error report:

g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/usr/local/include -DOS_LINUX -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -I/usr/lib64/wx/include/gtk

2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -c src/DOFrame.cpp
src/DOFrame.cpp: In member function ‘void DOFrame::LoadConfig(char*, int)’:
src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]
In file included from /usr/include/wx-2.8/wx/memory.h:16:0,
                 from /usr/include/wx-2.8/wx/object.h:20,
                 from /usr/include/wx-2.8/wx/wx.h:16,
                 from include/DRSOscInc.h:9,
                 from src/DOFrame.cpp:9:
/usr/include/wx-2.8/wx/string.h:1413:13: error:   initializing argument 1 of ‘wxString& wxString::operator+=(wxChar)’ [-fpermissive]
    Reply  Fri Sep 12 16:08:49 2014, Stefan Ritt, compilation error for v5.0.2 

Dmitry Hits wrote:

 Hi,

I am getting the following compilation error when trying to compile version 5.0.2 software:

src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]
 
I have wxWidgets v. 2.8.12 package on Fedora version 3.9.10-100.fc17.x86_64
 
Has anyone seen this before?
 
Thank you,
 
Dmitry 

 

---------------------------------------------------------------------------------------------

Full error report:

g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/usr/local/include -DOS_LINUX -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -I/usr/lib64/wx/include/gtk

2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -c src/DOFrame.cpp
src/DOFrame.cpp: In member function ‘void DOFrame::LoadConfig(char*, int)’:
src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]
In file included from /usr/include/wx-2.8/wx/memory.h:16:0,
                 from /usr/include/wx-2.8/wx/object.h:20,
                 from /usr/include/wx-2.8/wx/wx.h:16,
                 from include/DRSOscInc.h:9,
                 from src/DOFrame.cpp:9:
/usr/include/wx-2.8/wx/string.h:1413:13: error:   initializing argument 1 of ‘wxString& wxString::operator+=(wxChar)’ [-fpermissive]

I don't get this error under gcc 4.4.7, so I guess you have a newer version. Each one becomes more picky. Just try to replace

str += filename; 

with

str += (wxString) filename;

in line 617 of DOFrame.cpp

/Stefan

 

       Reply  Fri Sep 12 16:38:24 2014, Dmitry Hits, compilation error for v5.0.2 

Stefan Ritt wrote:

Dmitry Hits wrote:

 Hi,

I am getting the following compilation error when trying to compile version 5.0.2 software:

src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]
 
I have wxWidgets v. 2.8.12 package on Fedora version 3.9.10-100.fc17.x86_64
 
Has anyone seen this before?
 
Thank you,
 
Dmitry 

 

---------------------------------------------------------------------------------------------

Full error report:

g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/usr/local/include -DOS_LINUX -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -I/usr/lib64/wx/include/gtk

2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -c src/DOFrame.cpp
src/DOFrame.cpp: In member function ‘void DOFrame::LoadConfig(char*, int)’:
src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]
In file included from /usr/include/wx-2.8/wx/memory.h:16:0,
                 from /usr/include/wx-2.8/wx/object.h:20,
                 from /usr/include/wx-2.8/wx/wx.h:16,
                 from include/DRSOscInc.h:9,
                 from src/DOFrame.cpp:9:
/usr/include/wx-2.8/wx/string.h:1413:13: error:   initializing argument 1 of ‘wxString& wxString::operator+=(wxChar)’ [-fpermissive]

I don't get this error under gcc 4.4.7, so I guess you have a newer version. Each one becomes more picky. Just try to replace

str += filename; 

with

str += (wxString) filename;

in line 617 of DOFrame.cpp

/Stefan

 

Hi Stefan,

 

Unfortunately that did not work and from suggestions in the error I do see a good solution:

----------------------------

src/DOFrame.cpp: In member function ‘void DOFrame::LoadConfig(char*, int)’:

src/DOFrame.cpp:617:25: error: call of overloaded ‘wxString(char [1024])’ is ambiguous

src/DOFrame.cpp:617:25: note: candidates are:

/usr/include/wx-2.8/wx/string.h:722:3: note: wxString::wxString(const wxWCharBuffer&) <near match>

/usr/include/wx-2.8/wx/string.h:722:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘const wxWCharBuffer&’

/usr/include/wx-2.8/wx/string.h:692:3: note: wxString::wxString(wxChar, size_t) <near match>

/usr/include/wx-2.8/wx/string.h:692:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘wxChar {aka wchar_t}’

/usr/include/wx-2.8/wx/string.h:690:3: note: wxString::wxString(const wxString&) <near match>

/usr/include/wx-2.8/wx/string.h:690:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘const wxString&’

/usr/include/wx-2.8/wx/string.h:682:3: note: wxString::wxString(int) <near match>

/usr/include/wx-2.8/wx/string.h:682:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘int’

---------------------------------

 

let me know if you see one.

 

Thank you,

 

Dmitry.

 

 

 

_____________________________________________________________________________________________________________________________________________

Full error:

++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/usr/local/include -DOS_LINUX -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -I/usr/lib64/wx/include/gtk

2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -c src/DOFrame.cpp

src/DOFrame.cpp: In member function ‘void DOFrame::LoadConfig(char*, int)’:

src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]

In file included from /usr/include/wx-2.8/wx/memory.h:16:0,

                 from /usr/include/wx-2.8/wx/object.h:20,

                 from /usr/include/wx-2.8/wx/wx.h:16,

                 from include/DRSOscInc.h:9,

                 from src/DOFrame.cpp:9:

/usr/include/wx-2.8/wx/string.h:1413:13: error:   initializing argument 1 of ‘wxString& wxString::operator+=(wxChar)’ [-fpermissive]

[dmitry@kitkat ~]$ more error-drs4v5_2

g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/usr/local/include -DOS_LINUX -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -I/usr/lib64/wx/include/gtk

2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -c src/DOFrame.cpp

src/DOFrame.cpp: In member function ‘void DOFrame::LoadConfig(char*, int)’:

src/DOFrame.cpp:617:25: error: call of overloaded ‘wxString(char [1024])’ is ambiguous

src/DOFrame.cpp:617:25: note: candidates are:

In file included from /usr/include/wx-2.8/wx/memory.h:16:0,

                 from /usr/include/wx-2.8/wx/object.h:20,

                 from /usr/include/wx-2.8/wx/wx.h:16,

                 from include/DRSOscInc.h:9,

                 from src/DOFrame.cpp:9:

/usr/include/wx-2.8/wx/string.h:722:3: note: wxString::wxString(const wxWCharBuffer&) <near match>

/usr/include/wx-2.8/wx/string.h:722:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘const wxWCharBuffer&’

/usr/include/wx-2.8/wx/string.h:692:3: note: wxString::wxString(wxChar, size_t) <near match>

/usr/include/wx-2.8/wx/string.h:692:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘wxChar {aka wchar_t}’

/usr/include/wx-2.8/wx/string.h:690:3: note: wxString::wxString(const wxString&) <near match>

/usr/include/wx-2.8/wx/string.h:690:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘const wxString&’

/usr/include/wx-2.8/wx/string.h:682:3: note: wxString::wxString(int) <near match>

/usr/include/wx-2.8/wx/string.h:682:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘int’

make: *** [DOFrame.o] Error 1 

          Reply  Mon Sep 22 14:52:21 2014, Stefan Ritt, compilation error for v5.0.2 

Dmitry Hits wrote:

Stefan Ritt wrote:

Dmitry Hits wrote:

 Hi,

I am getting the following compilation error when trying to compile version 5.0.2 software:

src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]
 
I have wxWidgets v. 2.8.12 package on Fedora version 3.9.10-100.fc17.x86_64
 
Has anyone seen this before?
 
Thank you,
 
Dmitry 

 

---------------------------------------------------------------------------------------------

Full error report:

g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/usr/local/include -DOS_LINUX -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -I/usr/lib64/wx/include/gtk

2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -c src/DOFrame.cpp
src/DOFrame.cpp: In member function ‘void DOFrame::LoadConfig(char*, int)’:
src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]
In file included from /usr/include/wx-2.8/wx/memory.h:16:0,
                 from /usr/include/wx-2.8/wx/object.h:20,
                 from /usr/include/wx-2.8/wx/wx.h:16,
                 from include/DRSOscInc.h:9,
                 from src/DOFrame.cpp:9:
/usr/include/wx-2.8/wx/string.h:1413:13: error:   initializing argument 1 of ‘wxString& wxString::operator+=(wxChar)’ [-fpermissive]

I don't get this error under gcc 4.4.7, so I guess you have a newer version. Each one becomes more picky. Just try to replace

str += filename; 

with

str += (wxString) filename;

in line 617 of DOFrame.cpp

/Stefan

 

Hi Stefan,

 

Unfortunately that did not work and from suggestions in the error I do see a good solution:

----------------------------

src/DOFrame.cpp: In member function ‘void DOFrame::LoadConfig(char*, int)’:

src/DOFrame.cpp:617:25: error: call of overloaded ‘wxString(char [1024])’ is ambiguous

src/DOFrame.cpp:617:25: note: candidates are:

/usr/include/wx-2.8/wx/string.h:722:3: note: wxString::wxString(const wxWCharBuffer&) <near match>

/usr/include/wx-2.8/wx/string.h:722:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘const wxWCharBuffer&’

/usr/include/wx-2.8/wx/string.h:692:3: note: wxString::wxString(wxChar, size_t) <near match>

/usr/include/wx-2.8/wx/string.h:692:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘wxChar {aka wchar_t}’

/usr/include/wx-2.8/wx/string.h:690:3: note: wxString::wxString(const wxString&) <near match>

/usr/include/wx-2.8/wx/string.h:690:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘const wxString&’

/usr/include/wx-2.8/wx/string.h:682:3: note: wxString::wxString(int) <near match>

/usr/include/wx-2.8/wx/string.h:682:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘int’

---------------------------------

 

let me know if you see one.

 

Thank you,

 

Dmitry.

 

 

 

_____________________________________________________________________________________________________________________________________________

Full error:

++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/usr/local/include -DOS_LINUX -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -I/usr/lib64/wx/include/gtk

2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -c src/DOFrame.cpp

src/DOFrame.cpp: In member function ‘void DOFrame::LoadConfig(char*, int)’:

src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]

In file included from /usr/include/wx-2.8/wx/memory.h:16:0,

                 from /usr/include/wx-2.8/wx/object.h:20,

                 from /usr/include/wx-2.8/wx/wx.h:16,

                 from include/DRSOscInc.h:9,

                 from src/DOFrame.cpp:9:

/usr/include/wx-2.8/wx/string.h:1413:13: error:   initializing argument 1 of ‘wxString& wxString::operator+=(wxChar)’ [-fpermissive]

[dmitry@kitkat ~]$ more error-drs4v5_2

g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/usr/local/include -DOS_LINUX -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -I/usr/lib64/wx/include/gtk

2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -c src/DOFrame.cpp

src/DOFrame.cpp: In member function ‘void DOFrame::LoadConfig(char*, int)’:

src/DOFrame.cpp:617:25: error: call of overloaded ‘wxString(char [1024])’ is ambiguous

src/DOFrame.cpp:617:25: note: candidates are:

In file included from /usr/include/wx-2.8/wx/memory.h:16:0,

                 from /usr/include/wx-2.8/wx/object.h:20,

                 from /usr/include/wx-2.8/wx/wx.h:16,

                 from include/DRSOscInc.h:9,

                 from src/DOFrame.cpp:9:

/usr/include/wx-2.8/wx/string.h:722:3: note: wxString::wxString(const wxWCharBuffer&) <near match>

/usr/include/wx-2.8/wx/string.h:722:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘const wxWCharBuffer&’

/usr/include/wx-2.8/wx/string.h:692:3: note: wxString::wxString(wxChar, size_t) <near match>

/usr/include/wx-2.8/wx/string.h:692:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘wxChar {aka wchar_t}’

/usr/include/wx-2.8/wx/string.h:690:3: note: wxString::wxString(const wxString&) <near match>

/usr/include/wx-2.8/wx/string.h:690:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘const wxString&’

/usr/include/wx-2.8/wx/string.h:682:3: note: wxString::wxString(int) <near match>

/usr/include/wx-2.8/wx/string.h:682:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘int’

make: *** [DOFrame.o] Error 1 

I just tried with the current Ubuntu version (gcc version 4.8.2, wxWidgets 3.0.1) and it worked without any problem. So please upgrade to wxWidgets 3.0.1

/Stefan

Entry  Mon Sep 15 16:24:41 2014, Hannes Wachter, Timing Calibration Fail 

Hi,

has anyone experienced a shutdown of the DRSosc.exe or DRScl.exe when executing a Timing Calibration? Also, when we add the command b->CalibrateTiming(NULL); to the drs_exam.cpp and run the exe, our program shuts down immediately and windows shows an error message (identical to DRSosc and DRScl).

Any help is appreciated.

 

    Reply  Mon Sep 22 15:04:37 2014, Stefan Ritt, Timing Calibration Fail 

Hannes Wachter wrote:

Hi,

has anyone experienced a shutdown of the DRSosc.exe or DRScl.exe when executing a Timing Calibration? Also, when we add the command b->CalibrateTiming(NULL); to the drs_exam.cpp and run the exe, our program shuts down immediately and windows shows an error message (identical to DRSosc and DRScl).

Any help is appreciated.

 

Actually there is no need to call b->CalibrateTiming() at all from drs_exam.cpp. The timing calibration, once executed, will remain valid over a wide temperature range and for very long time (years), so no need to redo it over and over again.

/Stefan 

Entry  Tue Oct 7 14:09:02 2014, Stephane Debieux, USB Microcontroller firmware 

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

    Reply  Mon Oct 13 16:46:56 2014, Stefan Ritt, USB Microcontroller firmware 

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

       Reply  Mon Oct 13 17:08:40 2014, Stephane Debieux, USB Microcontroller firmware 

Stefan Ritt wrote:

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

 Thank you Stefan.

Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?

Thank you.

Stephane

          Reply  Mon Oct 13 17:14:58 2014, Stefan Ritt, USB Microcontroller firmware 

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

 Thank you Stefan.

Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?

Thank you.

Stephane

There is only one drs_eval.c version around, and I confirm that it is the one in the distribution. If you use different compiler settings, like optimisations, you might get a different executable file (and thus a .iic file), but the files have the same functionality.

Stefan 

             Reply  Tue Oct 14 16:21:07 2014, Stephane Debieux, USB Microcontroller firmware 

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

 Thank you Stefan.

Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?

Thank you.

Stephane

There is only one drs_eval.c version around, and I confirm that it is the one in the distribution. If you use different compiler settings, like optimisations, you might get a different executable file (and thus a .iic file), but the files have the same functionality.

Stefan 

I'm very sorry to insist but if I take the .hex of the distribution, convert it to .iic using the hex2bix utility, and reprogram the board, I can't read the board correctly (invalid magic number read with drscl for instance). Also, when using the uVision2 project file you provide and compiling the drs_eval.c, I get the same result  (i.e. no way to generate a functional .iic file starting from the sources). So, either I'm doing something wrong (and I don't know what) or the drs_eval.c is not the correct one.

                Reply  Tue Oct 14 16:29:12 2014, Stefan Ritt, USB Microcontroller firmware 

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

 Thank you Stefan.

Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?

Thank you.

Stephane

There is only one drs_eval.c version around, and I confirm that it is the one in the distribution. If you use different compiler settings, like optimisations, you might get a different executable file (and thus a .iic file), but the files have the same functionality.

Stefan 

I'm very sorry to insist but if I take the .hex of the distribution, convert it to .iic using the hex2bix utility, and reprogram the board, I can't read the board correctly (invalid magic number read with drscl for instance). Also, when using the uVision2 project file you provide and compiling the drs_eval.c, I get the same result  (i.e. no way to generate a functional .iic file starting from the sources). So, either I'm doing something wrong (and I don't know what) or the drs_eval.c is not the correct one.

And what happens if you program the .iic file from the distribution? 

                   Reply  Tue Oct 14 16:34:45 2014, Stephane Debieux, USB Microcontroller firmware 

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

 Thank you Stefan.

Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?

Thank you.

Stephane

There is only one drs_eval.c version around, and I confirm that it is the one in the distribution. If you use different compiler settings, like optimisations, you might get a different executable file (and thus a .iic file), but the files have the same functionality.

Stefan 

I'm very sorry to insist but if I take the .hex of the distribution, convert it to .iic using the hex2bix utility, and reprogram the board, I can't read the board correctly (invalid magic number read with drscl for instance). Also, when using the uVision2 project file you provide and compiling the drs_eval.c, I get the same result  (i.e. no way to generate a functional .iic file starting from the sources). So, either I'm doing something wrong (and I don't know what) or the drs_eval.c is not the correct one.

And what happens if you program the .iic file from the distribution? 

It works as expected.

                      Reply  Tue Oct 14 16:38:14 2014, Stefan Ritt, USB Microcontroller firmware 

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

 Thank you Stefan.

Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?

Thank you.

Stephane

There is only one drs_eval.c version around, and I confirm that it is the one in the distribution. If you use different compiler settings, like optimisations, you might get a different executable file (and thus a .iic file), but the files have the same functionality.

Stefan 

I'm very sorry to insist but if I take the .hex of the distribution, convert it to .iic using the hex2bix utility, and reprogram the board, I can't read the board correctly (invalid magic number read with drscl for instance). Also, when using the uVision2 project file you provide and compiling the drs_eval.c, I get the same result  (i.e. no way to generate a functional .iic file starting from the sources). So, either I'm doing something wrong (and I don't know what) or the drs_eval.c is not the correct one.

And what happens if you program the .iic file from the distribution? 

It works as expected.

 Then why don't you use the .iic file and forget about the hex and c files? Honestly speaking, I don't remember what source file I compiled a couple of years ago, and it could be that an older file slipped into the repository, but that's all I have. I would have to investigate myself, try to compile and program the c file, do the debugging, and find out what the differences are. But unfortunately I don't have time for that right now. So just stick with the .iic file.

                         Reply  Tue Oct 14 16:51:37 2014, Stephane Debieux, USB Microcontroller firmware 

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

 Thank you Stefan.

Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?

Thank you.

Stephane

There is only one drs_eval.c version around, and I confirm that it is the one in the distribution. If you use different compiler settings, like optimisations, you might get a different executable file (and thus a .iic file), but the files have the same functionality.

Stefan 

I'm very sorry to insist but if I take the .hex of the distribution, convert it to .iic using the hex2bix utility, and reprogram the board, I can't read the board correctly (invalid magic number read with drscl for instance). Also, when using the uVision2 project file you provide and compiling the drs_eval.c, I get the same result  (i.e. no way to generate a functional .iic file starting from the sources). So, either I'm doing something wrong (and I don't know what) or the drs_eval.c is not the correct one.

And what happens if you program the .iic file from the distribution? 

It works as expected.

 Then why don't you use the .iic file and forget about the hex and c files? Honestly speaking, I don't remember what source file I compiled a couple of years ago, and it could be that an older file slipped into the repository, but that's all I have. I would have to investigate myself, try to compile and program the c file, do the debugging, and find out what the differences are. But unfortunately I don't have time for that right now. So just stick with the .iic file.

Thanks for the help.

I'm not doing this for fun, checking that the source matches the .iic ! I know I could directly use the .iic and forget about the hex and c files.

I just wanted to use your source file as the starting point for my own board, as everybody is doing at the application level.

Entry  Tue Aug 26 14:16:26 2014, Roman Gredig, binary files with more than 4 drs board ver. 5.0.2 
Dear Stefan

after having some problems with writing binary files with more than 4 drs boards (in multiboard-mode) I might 
have found the solution.
In the file src/Osci.cpp at line 838 is: 
unsigned char buffer[100000];

If I understand the binary format right, this works only with up to four boards. With the maximum number of 
boards in your specification (16 boards) and all channels switched on on all boards this array needs to have 
about 400000 entries (for the first event, where the time information is written too).

Could you please cross-check that?

Thank you very much!
Cheers,
Roman
    Reply  Thu Oct 16 16:15:16 2014, Stefan Ritt, binary files with more than 4 drs board ver. 5.0.2 
> Dear Stefan
> 
> after having some problems with writing binary files with more than 4 drs boards (in multiboard-mode) I might 
> have found the solution.
> In the file src/Osci.cpp at line 838 is: 
> unsigned char buffer[100000];
> 
> If I understand the binary format right, this works only with up to four boards. With the maximum number of 
> boards in your specification (16 boards) and all channels switched on on all boards this array needs to have 
> about 400000 entries (for the first event, where the time information is written too).
> 
> Could you please cross-check that?
> 
> Thank you very much!
> Cheers,
> Roman

This problem has been fixed in software version 5.0.3

/Stefan
Entry  Wed Aug 13 20:17:19 2014, Roman Gredig, binary files time calibration header in drs-5.0.2 
Dear Stefan

I have a problem considering binary data files.
Usually binary files start with TIME... (the time calibration header). But I observed the following reproducible problem.
1. Start to save a binary file (e.g. 001.dat) with 1000000 events. 
2. Hit the close button before this limit has reached. (so far the binary files seems to be ok) 
3. Start to save again a file with the SAME filename (and agree to replace the already existing it)
If I do it like this, the file has no time information anymore and starts directly with EHDR.

could it be that the m_evSerial counter is not reset in this specific situation?

Cheers,
Roman
    Reply  Thu Oct 16 16:16:12 2014, Stefan Ritt, binary files time calibration header in drs-5.0.2 
> Dear Stefan
> 
> I have a problem considering binary data files.
> Usually binary files start with TIME... (the time calibration header). But I observed the following reproducible problem.
> 1. Start to save a binary file (e.g. 001.dat) with 1000000 events. 
> 2. Hit the close button before this limit has reached. (so far the binary files seems to be ok) 
> 3. Start to save again a file with the SAME filename (and agree to replace the already existing it)
> If I do it like this, the file has no time information anymore and starts directly with EHDR.
> 
> could it be that the m_evSerial counter is not reset in this specific situation?
> 
> Cheers,
> Roman

This problem has also been fixed in version 5.0.3

/Stefan
Entry  Sun Oct 19 14:36:54 2014, Chris Tully, coverting the xml file format into binary 

 Hi,

    Is there a straightforward way to convert the xml file format into the binary format?  I have some runs taken mistakenly with xml.

Best,

Chris

 

Entry  Mon Nov 17 16:36:18 2014, Mickey Chiu, Raspberry Pi drsosc does not exit properly 

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.

    Reply  Tue Nov 25 14:06:34 2014, Stefan Ritt, Raspberry Pi drsosc does not exit properly 

Mickey Chiu wrote:

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 

Entry  Fri Jan 16 13:29:05 2015, Rainer Hentges, Mac OSX Yosemite 10.10 
Hello,

I can compile version 5.0.3 of DRS4sc on Mac OSX 10.0 without errors but when I want to execute the program I get the following error:

[home]$ ./DRSOsc
DRSOsc(48068,0x7fff7ac5e300) malloc: *** error for object 0x7f88d9434a80: incorrect checksum for freed object - object was probably 
modified after being freed.
*** set a breakpoint in malloc_error_break to debug

Is this a known error? Will it be fixed in the next release?
    Reply  Fri Jan 16 14:12:19 2015, Stefan Ritt, Mac OSX Yosemite 10.10 
> Hello,
> 
> I can compile version 5.0.3 of DRS4sc on Mac OSX 10.0 without errors but when I want to execute the program I get the following error:
> 
> [home]$ ./DRSOsc
> DRSOsc(48068,0x7fff7ac5e300) malloc: *** error for object 0x7f88d9434a80: incorrect checksum for freed object - object was probably 
> modified after being freed.
> *** set a breakpoint in malloc_error_break to debug
> 
> Is this a known error? Will it be fixed in the next release?

When I compile on OSX 10.10.1 with XCode 6.1.1 I get no error. I'm using wxWidgets 3.0.0. Same when I compile with the command line 
tools (which you first have to install from Apple) via "make", "make app", "open ./DRSOsc.app". You cannot start a graphical program 
directly from the command line like under Linux, you have to make an app and the do "open <app>".

Best regards,
Stefan
Entry  Fri Feb 13 10:12:16 2015, Andrzej Grzeszczuk, drs4 and root 

Hello,

I compiled base file for drs system  (DRS.cpp) to root framework (root.cern.ch) as dynamic library DRS.so. It can be used for building many kind of applications under the root system. I applied it for older version of  root 5.28 and for latest version 6.02 too.

If anyone is interesting, I can help, please write to me andrzej.grzeszczuk@us.edu.pl

Regards

Andrzej

Entry  Mon Mar 16 16:07:39 2015, Hermann-Josef Mathes, Running 2 instances of a DRS DAQ program 

Hi,

we want to run two instances of our little DRS DAQ program but obviously the first instance started always claims all DRS boards for itself and the other one exits with an error. The 2 boards used in the example below have the serial number # 2413 and #2414 and are v5 boards.

The first one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2413
DRSController: found board with serial number #2413
DRSController: found board with serial number #2414
DRSController: using board with serial number #2413
CalibratedFrequency= 1.00721
====================================
DRS type:            DRS4
Board type:          9
Serial number:       2413
Firmware revision:   21260

...
And the second one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2414
musb_open: usb_set_configuration() error -6
musb_open: Found USB device 0x04b4:0x1175 instance 0, but cannot initialize it: please check permissions on "/proc/bus/usb/1/7" and "/dev/bus/usb/1/7"
USB successfully scanned, but no boards found
...


How can our goal be achieved?

Thanks

Hermann-Josef

    Reply  Tue Mar 17 02:53:26 2015, Stefan Ritt, Running 2 instances of a DRS DAQ program 

I never had in mind running two systems in parallel, that's why the code claims all interfaces when started. You have to dig into the usb code which is located in musbstd.c at function musb_open(). There you will find a line libusb_claim_interface() which requests exclusive access to the usb subsystem. The code is there because I copied it from some standard example for the libusb library. You have to read the documentation for libusb (http://libusb.sourceforge.net/api-1.0/) and see if you can get rid of that. Probaby you have to claim/release the interface on each access, but I never tried that.

Stefan

Hermann-Josef Mathes wrote:

Hi,

we want to run two instances of our little DRS DAQ program but obviously the first instance started always claims all DRS boards for itself and the other one exits with an error. The 2 boards used in the example below have the serial number # 2413 and #2414 and are v5 boards.

The first one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2413
DRSController: found board with serial number #2413
DRSController: found board with serial number #2414
DRSController: using board with serial number #2413
CalibratedFrequency= 1.00721
====================================
DRS type:            DRS4
Board type:          9
Serial number:       2413
Firmware revision:   21260

...
And the second one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2414
musb_open: usb_set_configuration() error -6
musb_open: Found USB device 0x04b4:0x1175 instance 0, but cannot initialize it: please check permissions on "/proc/bus/usb/1/7" and "/dev/bus/usb/1/7"
USB successfully scanned, but no boards found
...


How can our goal be achieved?

Thanks

Hermann-Josef

 

       Reply  Thu Mar 19 07:37:52 2015, Daniel Stricker-Shaver, Running 2 instances of a DRS DAQ program 

I don't know if it helps, but we measured the time resolution between two independendly running v3 boards using a single PC (latest software) in Linux. (http://arxiv.org/abs/1405.4975)

You start the DRS DAQ program with only one USB board connected, first. Afterwards connect the second board and start another session. If you externally trigger (global) both boards with less than 1 Hz, you can garantee that both programs save the same events independently (from two individual DRS boards).

Daniel

Stefan Ritt wrote:

I never had in mind running two systems in parallel, that's why the code claims all interfaces when started. You have to dig into the usb code which is located in musbstd.c at function musb_open(). There you will find a line libusb_claim_interface() which requests exclusive access to the usb subsystem. The code is there because I copied it from some standard example for the libusb library. You have to read the documentation for libusb (http://libusb.sourceforge.net/api-1.0/) and see if you can get rid of that. Probaby you have to claim/release the interface on each access, but I never tried that.

Stefan

Hermann-Josef Mathes wrote:

Hi,

we want to run two instances of our little DRS DAQ program but obviously the first instance started always claims all DRS boards for itself and the other one exits with an error. The 2 boards used in the example below have the serial number # 2413 and #2414 and are v5 boards.

The first one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2413
DRSController: found board with serial number #2413
DRSController: found board with serial number #2414
DRSController: using board with serial number #2413
CalibratedFrequency= 1.00721
====================================
DRS type:            DRS4
Board type:          9
Serial number:       2413
Firmware revision:   21260

...
And the second one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2414
musb_open: usb_set_configuration() error -6
musb_open: Found USB device 0x04b4:0x1175 instance 0, but cannot initialize it: please check permissions on "/proc/bus/usb/1/7" and "/dev/bus/usb/1/7"
USB successfully scanned, but no boards found
...


How can our goal be achieved?

Thanks

Hermann-Josef

 

 

Entry  Wed Oct 15 10:14:32 2014, Simon Weingarten, Clock settings in daisy chain DAQ 

Hi,

I'm currently working on a little DAQ system with four DRS evaluation boards. Do i need to apply any specific settings when using the clock in/out connectors for synchronization? I do not see anything like that in the drs_exam_multi example.

Any help would be greatly appreciated!

Best,

Simon

    Reply  Wed Oct 15 10:52:58 2014, Stefan Ritt, Clock settings in daisy chain DAQ 

Simon Weingarten wrote:

Hi,

I'm currently working on a little DAQ system with four DRS evaluation boards. Do i need to apply any specific settings when using the clock in/out connectors for synchronization? I do not see anything like that in the drs_exam_multi example.

Any help would be greatly appreciated!

Best,

Simon

Right, I did not yet put any code there. What you need on all slave boards is

b->SetRefclk(true);

b->SetFrequency(...);

Set SetFrequency() is needed to restart the boards with the external clock.

This works of course only if you have the clock signals connected as written in the manual. If not, the boards won't work after you switch the reference clock.

Best regards,
Stefan 

       Reply  Wed Oct 15 11:34:43 2014, Simon Weingarten, Clock settings in daisy chain DAQ 

Stefan Ritt wrote:

Simon Weingarten wrote:

Hi,

I'm currently working on a little DAQ system with four DRS evaluation boards. Do i need to apply any specific settings when using the clock in/out connectors for synchronization? I do not see anything like that in the drs_exam_multi example.

Any help would be greatly appreciated!

Best,

Simon

Right, I did not yet put any code there. What you need on all slave boards is

b->SetRefclk(true);

b->SetFrequency(...);

Set SetFrequency() is needed to restart the boards with the external clock.

This works of course only if you have the clock signals connected as written in the manual. If not, the boards won't work after you switch the reference clock.

Best regards,
Stefan 

Thank you so much for the fast reply! I'll give it a try.

 

Best regards,

Simon

       Reply  Wed Oct 15 12:15:58 2014, Stefan Ritt, Clock settings in daisy chain DAQ drs_exam_multi.cpp

Here is the full version of the program with clock daisy-chaining. Before switching to the external clock, it checks if the clock really is there (by reading an internal scaler), and only then enables it. Note that the code also works without clock daisy-chaining. But without clock daisy-chaining your have some 400 ps time resolution between boards, and with clock daisy-chaining you get some 60 ps.

          Reply  Fri Apr 17 10:07:38 2015, Simon Weingarten, Clock settings in daisy chain DAQ 

Hi Stefan,

do you know how these numbers (400ps and 60ps) scale with the sampling rate? The manual says they are for 5GS/s, do they change with slower sampling?

Thanks and best regards,

Simon

Stefan Ritt wrote:

Here is the full version of the program with clock daisy-chaining. Before switching to the external clock, it checks if the clock really is there (by reading an internal scaler), and only then enables it. Note that the code also works without clock daisy-chaining. But without clock daisy-chaining your have some 400 ps time resolution between boards, and with clock daisy-chaining you get some 60 ps.

 

             Reply  Mon Apr 20 13:08:24 2015, Stefan Ritt, Clock settings in daisy chain DAQ 

The resolution coming from the sampling rate goes into these numbers, but just marginally. At 5 GSPS, you get a few ps reolution, while at 1 GSPS, you get like 15 ps. If you convolve 15 ps with 400 ps, you get 400.3 ps, which is not significantly worse than 400 ps.

Simon Weingarten wrote:

Hi Stefan,

do you know how these numbers (400ps and 60ps) scale with the sampling rate? The manual says they are for 5GS/s, do they change with slower sampling?

Thanks and best regards,

Simon

Stefan Ritt wrote:

Here is the full version of the program with clock daisy-chaining. Before switching to the external clock, it checks if the clock really is there (by reading an internal scaler), and only then enables it. Note that the code also works without clock daisy-chaining. But without clock daisy-chaining your have some 400 ps time resolution between boards, and with clock daisy-chaining you get some 60 ps.

 

 

Entry  Thu Apr 9 11:46:33 2015, Felix Bachmair, DRSBoard::SetTriggerSource 

Hi

I have a question about the function SetTriggerSource in the class DRSBoard (DRS.h/DRS.cpp)

In the implementation there is the following comment:

// Set trigger configuration

// OR 0=CH1, 1=CH2, 2=CH3, 3=CH4, 4=EXT

// AND 8=CH1, 9=CH2, 10=CH3, 11=CH4, 12=EXT

 

What does this exactly mean? I am assuming that this are the bits which are set?

e.g

source = 1 ==> CH1

source = 4352 = 0x1100 ==> CH1 and ext

How is the AND/Or logic implemented?

When i have:

source = 0x1803 (bit 12,11,1,0)

what is the right way to set the brackets to expalin the logic?

(EXT and CH4 ) or CH2 or CH1 ?

 

Cheers Felix Bachmair

ETH Zurich

    Reply  Tue Apr 21 12:01:45 2015, Stefan Ritt, DRSBoard::SetTriggerSource 

Your first assumption is correct, e.g.

source = 00000000'00000001 = 0x0001 ==> CH1

source = 00010001'00000000 = 0x1100 ==> CH1 and EXT

So the lower byte is the "OR" block, and the upper byte is the "AND" block. Both blocks are combined via an "OR" so

source = 00011000'00000011 = 0x1803 is (EXT and CH4) OR (CH1 or CH2)

The "OR" combination between the two blocks is fixed in the firmware and cannot be changed without changing the firmware, but theoretically any logical combination between five inputs would be possible if you touch thr firmware.

/Stefan

 

Felix Bachmair wrote:

Hi

I have a question about the function SetTriggerSource in the class DRSBoard (DRS.h/DRS.cpp)

In the implementation there is the following comment:

// Set trigger configuration

// OR 0=CH1, 1=CH2, 2=CH3, 3=CH4, 4=EXT

// AND 8=CH1, 9=CH2, 10=CH3, 11=CH4, 12=EXT

 

What does this exactly mean? I am assuming that this are the bits which are set?

e.g

source = 1 ==> CH1

source = 4352 = 0x1100 ==> CH1 and ext

How is the AND/Or logic implemented?

When i have:

source = 0x1803 (bit 12,11,1,0)

what is the right way to set the brackets to expalin the logic?

(EXT and CH4 ) or CH2 or CH1 ?

 

Cheers Felix Bachmair

ETH Zurich

 

Entry  Sun Apr 5 22:16:48 2015, Julien Wulf, DRS4 Evaluation Board Baseline/Voltage Calibration  

Hi,

I`m trying to calibrate my DRS4 evoluation board to an input range of 0-1V but it doesn`t work.

1) First I tried to calibrate it with the drsosc (version 5.0.3) Software. The -0.5V - 0.5V calibration works, but during the 0 - 1V calibration the Software crashes.

2) I also tried to calibrate the input range with a C++ DAQ Package (based on drs_exam). Here the code of the calibration:

    ....

    b->SetInputRange(0.) (Center at 0 V )

    b->CalibrateVolt(NULL);

   ....

   Calibration Works

   ....

   b->SetInputRange(0.5) (Center at 0.5 V )

   b->CalibrateVolt(NULL);

  ....

   Results in: Found 4096 stuck pixels on this board.

Did I do a mistake or is this a normal behaviour of the board? Also the board often crashes and I get a magic number 0000 after restarting the DAQ. Then the board needs to be restarted via pulling the plug. ( I ensured that I terminate the USB connection before I close the program with "delete drs"). Is there a possibility to avoid this error?

My OS: Ubuntu 14.04 LTS.

Ciao,

Julien

    Reply  Tue Apr 21 12:52:18 2015, Stefan Ritt, DRS4 Evaluation Board Baseline/Voltage Calibration  

1) I tried to cablirate a V5 board with drsosc 5.0.3 and it just worked fine for me. No idea what went wrong in your case.

2) The "found 4096 stuck pixels on this board" can be safely ignored. It comes from the fact that the standard evaluation board has four cannels unconnected (the DRS4 chip has 8 channels, four are connected to in the evaluation board and four are unconnected). So the software sees wrong values on four channels because they are unconnected and thinks something is wrong. Unfortunately the software cannot determine if the channels are connected or not. So just ignore it.

3) I heard several people having to reset their boards under Linux in a similar way than you. This is probalby due to some instability in the USB part of the linux kernel, since the problem does not occur on other systems (Windows, Mac OSX). So I cannot do anything from the software side.

/Stefan

Julien Wulf wrote:

Hi,

I`m trying to calibrate my DRS4 evoluation board to an input range of 0-1V but it doesn`t work.

1) First I tried to calibrate it with the drsosc (version 5.0.3) Software. The -0.5V - 0.5V calibration works, but during the 0 - 1V calibration the Software crashes.

2) I also tried to calibrate the input range with a C++ DAQ Package (based on drs_exam). Here the code of the calibration:

    ....

    b->SetInputRange(0.) (Center at 0 V )

    b->CalibrateVolt(NULL);

   ....

   Calibration Works

   ....

   b->SetInputRange(0.5) (Center at 0.5 V )

   b->CalibrateVolt(NULL);

  ....

   Results in: Found 4096 stuck pixels on this board.

Did I do a mistake or is this a normal behaviour of the board? Also the board often crashes and I get a magic number 0000 after restarting the DAQ. Then the board needs to be restarted via pulling the plug. ( I ensured that I terminate the USB connection before I close the program with "delete drs"). Is there a possibility to avoid this error?

My OS: Ubuntu 14.04 LTS.

Ciao,

Julien

 

       Reply  Tue Apr 21 13:03:38 2015, Daniel Stricker-Shaver, DRS4 Evaluation Board Baseline/Voltage Calibration  

I also use Ubuntu 14.04 LTS and for my V3 borad I have to use drsosc 4.x or ealier to perform the calibration.

Stefan Ritt wrote:

1) I tried to cablirate a V5 board with drsosc 5.0.3 and it just worked fine for me. No idea what went wrong in your case.

2) The "found 4096 stuck pixels on this board" can be safely ignored. It comes from the fact that the standard evaluation board has four cannels unconnected (the DRS4 chip has 8 channels, four are connected to in the evaluation board and four are unconnected). So the software sees wrong values on four channels because they are unconnected and thinks something is wrong. Unfortunately the software cannot determine if the channels are connected or not. So just ignore it.

3) I heard several people having to reset their boards under Linux in a similar way than you. This is probalby due to some instability in the USB part of the linux kernel, since the problem does not occur on other systems (Windows, Mac OSX). So I cannot do anything from the software side.

/Stefan

Julien Wulf wrote:

Hi,

I`m trying to calibrate my DRS4 evoluation board to an input range of 0-1V but it doesn`t work.

1) First I tried to calibrate it with the drsosc (version 5.0.3) Software. The -0.5V - 0.5V calibration works, but during the 0 - 1V calibration the Software crashes.

2) I also tried to calibrate the input range with a C++ DAQ Package (based on drs_exam). Here the code of the calibration:

    ....

    b->SetInputRange(0.) (Center at 0 V )

    b->CalibrateVolt(NULL);

   ....

   Calibration Works

   ....

   b->SetInputRange(0.5) (Center at 0.5 V )

   b->CalibrateVolt(NULL);

  ....

   Results in: Found 4096 stuck pixels on this board.

Did I do a mistake or is this a normal behaviour of the board? Also the board often crashes and I get a magic number 0000 after restarting the DAQ. Then the board needs to be restarted via pulling the plug. ( I ensured that I terminate the USB connection before I close the program with "delete drs"). Is there a possibility to avoid this error?

My OS: Ubuntu 14.04 LTS.

Ciao,

Julien

 

 

          Reply  Tue Apr 21 13:06:39 2015, Stefan Ritt, DRS4 Evaluation Board Baseline/Voltage Calibration  

Sure, for a V3 board you need a pre-V5 software, but I assumed Julien had a V5 board. 

Daniel Stricker-Shaver wrote:

I also use Ubuntu 14.04 LTS and for my V3 borad I have to use drsosc 4.x or ealier to perform the calibration.

Entry  Wed May 13 01:07:36 2015, Cosmin Deaconu, DRS4 Evaluation Board + Powered USB Hub 

I am trying to use 4 evaluation boards with a powered USB hub (since eventually, I will have to do this on a laptop).  It seems like destroying the DRS object is insufficent to properly close the boards when on the hub (i.e. I get usb read errors next time I run my program). When all the boards are plugged into the computer, all is fine.  This is on Linux using libusb1. My guess is something about resetting the port doesn't work properly (but maybe that's this particular hub's fault?).  Has anyone else experienced a similar issue. If not, can someone recommend a hub that is known to work?

Entry  Wed May 13 00:52:51 2015, Cosmin Deaconu, Getting Trigger Source 

I'd like to be able to know which channel (0,1,2,3 or external) was responsible for the trigger.  DRSBoard::GetTriggerSource() seems to always return 1.  Is there a way to get this information?  Using the DRS4 evaluation board and software version 5.0.3.

Thanks,

Cosmin

 

    Reply  Wed May 13 08:19:53 2015, Stefan Ritt, Getting Trigger Source 

DRSBoard::GetTriggerSource() simply returns what has been enabled via DRSBoard::SetTriggerSource(). The actual source which causes the trigger is not stored in the hardware of the board, because I can be reconstructed easily from the waveforms. So just look which of the channels is above your trigger threshold. If none of the channels has a waveform obove the threshold, then the trigger must have been come from the external trigger.

Cosmin Deaconu wrote:

I'd like to be able to know which channel (0,1,2,3 or external) was responsible for the trigger.  DRSBoard::GetTriggerSource() seems to always return 1.  Is there a way to get this information?  Using the DRS4 evaluation board and software version 5.0.3.

Thanks,

Cosmin

 

 

Entry  Wed May 13 09:31:18 2015, Chenfei Yang, transparent-mode voltage tek00000_.png

Hello Mr. Stefan Ritt

  For DRS4 differential inputs ranges form 500mV to 1100mV, with ROFS set to 1.55V, O_OFS set to 1.3V, the outputs of DRS4 is shown in the attachment.

  The left part of the waveform,DRS4 works in transparent mode, and then the readout take place. The DMV of transparent mode is bigger then the readout mode, and that makes ADC sampling harder.How may I solve this problem?

  Best wishes!

                                 Chenfei Yang

    Reply  Wed May 13 09:45:51 2015, Stefan Ritt, transparent-mode voltage 

The ROFS signal has no effect in the transparent mode, so you have to adjust O_OFS between sampling and transparent mode accordingly. Either use a DAC or two voltages with an analog switch.

Chenfei Yang wrote:

Hello Mr. Stefan Ritt

  For DRS4 differential inputs ranges form 500mV to 1100mV, with ROFS set to 1.55V, O_OFS set to 1.3V, the outputs of DRS4 is shown in the attachment.

  The left part of the waveform,DRS4 works in transparent mode, and then the readout take place. The DMV of transparent mode is bigger then the readout mode, and that makes ADC sampling harder.How may I solve this problem?

  Best wishes!

                                 Chenfei Yang

 

       Reply  Wed May 13 09:55:09 2015, Chenfei Yang, transparent-mode voltage 

Here's the problem. My external ADC has 2Vpp differtial input voltage range. And the common-mode voltage of the inputs need to be 1.3V. I cannot make both the transparent-output and the readout-output meet the ADC input requirement.

Stefan Ritt wrote:

The ROFS signal has no effect in the transparent mode, so you have to adjust O_OFS between sampling and transparent mode accordingly. Either use a DAC or two voltages with an analog switch.

Chenfei Yang wrote:

Hello Mr. Stefan Ritt

  For DRS4 differential inputs ranges form 500mV to 1100mV, with ROFS set to 1.55V, O_OFS set to 1.3V, the outputs of DRS4 is shown in the attachment.

  The left part of the waveform,DRS4 works in transparent mode, and then the readout take place. The DMV of transparent mode is bigger then the readout mode, and that makes ADC sampling harder.How may I solve this problem?

  Best wishes!

                                 Chenfei Yang

 

 

          Reply  Wed May 13 10:16:40 2015, Stefan Ritt, transparent-mode voltage 

I see your point. Actually I will soon have the same issue since we design right now a board with an AD9637 using the transparent mode. Which one are you using? The common mode range given in the datasheet is limited to guarantee optimal performance. But some ADCs allow a slightly bigger common mode range with reduced performance, but which might still be ok for some application. A "real" solution would be to put switchable level shifters between the DRS and the ADC, but that requires 8 additional chips which is bad. Alternative the ADC could pick up the signal not at the DRS output but at the DRS input, but that would aslo require additional chips for multiplexing. So unfortunately no perfect solution for that...

Chenfei Yang wrote:

Here's the problem. My external ADC has 2Vpp differtial input voltage range. And the common-mode voltage of the inputs need to be 1.3V. I cannot make both the transparent-output and the readout-output meet the ADC input requirement.

Stefan Ritt wrote:

The ROFS signal has no effect in the transparent mode, so you have to adjust O_OFS between sampling and transparent mode accordingly. Either use a DAC or two voltages with an analog switch.

Chenfei Yang wrote:

Hello Mr. Stefan Ritt

  For DRS4 differential inputs ranges form 500mV to 1100mV, with ROFS set to 1.55V, O_OFS set to 1.3V, the outputs of DRS4 is shown in the attachment.

  The left part of the waveform,DRS4 works in transparent mode, and then the readout take place. The DMV of transparent mode is bigger then the readout mode, and that makes ADC sampling harder.How may I solve this problem?

  Best wishes!

                                 Chenfei Yang

 

 

 

             Reply  Wed May 13 10:27:43 2015, Chenfei Yang, transparent-mode voltage 

I'm using an AD9252, 0.9V common mode voltage is suggested and I already use 8 un-switchable level shifters. Just as you said, this common mode range is recommended for optimum performance and the device can function over a wider range with reasonable performance. So I think I could adjust O_OFS to a minor level during transparent output.

Stefan Ritt wrote:

I see your point. Actually I will soon have the same issue since we design right now a board with an AD9637 using the transparent mode. Which one are you using? The common mode range given in the datasheet is limited to guarantee optimal performance. But some ADCs allow a slightly bigger common mode range with reduced performance, but which might still be ok for some application. A "real" solution would be to put switchable level shifters between the DRS and the ADC, but that requires 8 additional chips which is bad. Alternative the ADC could pick up the signal not at the DRS output but at the DRS input, but that would aslo require additional chips for multiplexing. So unfortunately no perfect solution for that...

Chenfei Yang wrote:

Here's the problem. My external ADC has 2Vpp differtial input voltage range. And the common-mode voltage of the inputs need to be 1.3V. I cannot make both the transparent-output and the readout-output meet the ADC input requirement.

Stefan Ritt wrote:

The ROFS signal has no effect in the transparent mode, so you have to adjust O_OFS between sampling and transparent mode accordingly. Either use a DAC or two voltages with an analog switch.

Chenfei Yang wrote:

Hello Mr. Stefan Ritt

  For DRS4 differential inputs ranges form 500mV to 1100mV, with ROFS set to 1.55V, O_OFS set to 1.3V, the outputs of DRS4 is shown in the attachment.

  The left part of the waveform,DRS4 works in transparent mode, and then the readout take place. The DMV of transparent mode is bigger then the readout mode, and that makes ADC sampling harder.How may I solve this problem?

  Best wishes!

                                 Chenfei Yang

 

 

 

 

             Reply  Wed May 13 12:34:49 2015, Stefan Ritt, transparent-mode voltage 

There might be a solution. How do you bias th input of the DRS4 chip? If you use a scheme as described in elog:84, you can bias DRS_IN+ and DRS_IN- as desired. Take for example a board input range of 0-1V. For a 0V input, you bias DRS_IN+ and DRS_IN- both with 0.9V. A 1V input signal then puts DRS_IN+ to 1.4V and DRS_IN-to 0.4 V. In the transparent mode, DRS_OUT+ = DRS_IN+ and DRS_OUT- = O-OFS - DRS_OUT+. So if you put O-OFS to 0.9V, you get for a 0V board input signal DRS_OUT- = 2*0.9V - DRS_OUT+ = 0.9V. So DRS_OUT+   = DRS_OUT- = 0.9 V which is in the middle of your ADC range. 

If you do now a DRS readout, you need a ROFS of roughly 0.9V. For a 0V input, the storage capacitors have a zero differential voltage (DRS_IN+ = DRS_IN- = 0.8V), so DRS_OUT+ = (0.8V - 0.8V) + ROFS  = 0.9V, and since you have O-OFS=0.9V, you will also get DRS_OUT- = 2*0.9V - DRS_OUT+ = 0.9V. So you ranges for transparent mode nad DRS readout mode will be roughly the same.

                Reply  Wed May 13 12:52:22 2015, Chenfei Yang, transparent-mode voltage 

Yes. I use exactly the same scheme as you mentioned. I'll try your solution.

Stefan Ritt wrote:

There might be a solution. How do you bias th input of the DRS4 chip? If you use a scheme as described in elog:84, you can bias DRS_IN+ and DRS_IN- as desired. Take for example a board input range of 0-1V. For a 0V input, you bias DRS_IN+ and DRS_IN- both with 0.9V. A 1V input signal then puts DRS_IN+ to 1.4V and DRS_IN-to 0.4 V. In the transparent mode, DRS_OUT+ = DRS_IN+ and DRS_OUT- = O-OFS - DRS_OUT+. So if you put O-OFS to 0.9V, you get for a 0V board input signal DRS_OUT- = 2*0.9V - DRS_OUT+ = 0.9V. So DRS_OUT+   = DRS_OUT- = 0.9 V which is in the middle of your ADC range. 

If you do now a DRS readout, you need a ROFS of roughly 0.9V. For a 0V input, the storage capacitors have a zero differential voltage (DRS_IN+ = DRS_IN- = 0.8V), so DRS_OUT+ = (0.8V - 0.8V) + ROFS  = 0.9V, and since you have O-OFS=0.9V, you will also get DRS_OUT- = 2*0.9V - DRS_OUT+ = 0.9V. So you ranges for transparent mode nad DRS readout mode will be roughly the same.

 

                Reply  Wed May 13 16:13:07 2015, Chenfei Yang, transparent-mode voltage 

If using a ROFS of 0.9V, the input would not between 1.05V~2.05V better non-linearity area. Is that appropriate?

Stefan Ritt wrote:

There might be a solution. How do you bias th input of the DRS4 chip? If you use a scheme as described in elog:84, you can bias DRS_IN+ and DRS_IN- as desired. Take for example a board input range of 0-1V. For a 0V input, you bias DRS_IN+ and DRS_IN- both with 0.9V. A 1V input signal then puts DRS_IN+ to 1.4V and DRS_IN-to 0.4 V. In the transparent mode, DRS_OUT+ = DRS_IN+ and DRS_OUT- = O-OFS - DRS_OUT+. So if you put O-OFS to 0.9V, you get for a 0V board input signal DRS_OUT- = 2*0.9V - DRS_OUT+ = 0.9V. So DRS_OUT+   = DRS_OUT- = 0.9 V which is in the middle of your ADC range. 

If you do now a DRS readout, you need a ROFS of roughly 0.9V. For a 0V input, the storage capacitors have a zero differential voltage (DRS_IN+ = DRS_IN- = 0.8V), so DRS_OUT+ = (0.8V - 0.8V) + ROFS  = 0.9V, and since you have O-OFS=0.9V, you will also get DRS_OUT- = 2*0.9V - DRS_OUT+ = 0.9V. So you ranges for transparent mode nad DRS readout mode will be roughly the same.

 

                   Reply  Wed May 13 16:25:24 2015, Stefan Ritt, transparent-mode voltage 

To get the good linearity, you need indeed ROFS = 1.05V. With a O-OFS of 0.9V, a zero input signal would give you DRS_OUT+=1.05V and DRS_OUT-=0.75V. I think this is till in the range of your ADC, right? So it's a tradeoff between linearity and available range. I do not know how nonlinear the DRS4 will be for ROFS < 1.05V, you have to try. If it's getting too bad, you still can correct for this off-line. 

Chenfei Yang wrote:

If using a ROFS of 0.9V, the input would not between 1.05V~2.05V better non-linearity area. Is that appropriate?

Stefan Ritt wrote:

There might be a solution. How do you bias th input of the DRS4 chip? If you use a scheme as described in elog:84, you can bias DRS_IN+ and DRS_IN- as desired. Take for example a board input range of 0-1V. For a 0V input, you bias DRS_IN+ and DRS_IN- both with 0.9V. A 1V input signal then puts DRS_IN+ to 1.4V and DRS_IN-to 0.4 V. In the transparent mode, DRS_OUT+ = DRS_IN+ and DRS_OUT- = O-OFS - DRS_OUT+. So if you put O-OFS to 0.9V, you get for a 0V board input signal DRS_OUT- = 2*0.9V - DRS_OUT+ = 0.9V. So DRS_OUT+   = DRS_OUT- = 0.9 V which is in the middle of your ADC range. 

If you do now a DRS readout, you need a ROFS of roughly 0.9V. For a 0V input, the storage capacitors have a zero differential voltage (DRS_IN+ = DRS_IN- = 0.8V), so DRS_OUT+ = (0.8V - 0.8V) + ROFS  = 0.9V, and since you have O-OFS=0.9V, you will also get DRS_OUT- = 2*0.9V - DRS_OUT+ = 0.9V. So you ranges for transparent mode nad DRS readout mode will be roughly the same.

 

 

Entry  Sun May 24 09:34:27 2015, Peter Steinberg, Peculiar behavior of time values for Rev5 DRS4 EB 

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

    Reply  Wed Jun 3 09:07:38 2015, Stefan Ritt, Peculiar behavior of time values for Rev5 DRS4 EB 

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

 

Peter Steinberg wrote:

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

 

Entry  Tue May 19 14:14:45 2015, Ilja Bekman, DRS4 firmware UCF constraints  
Hello, I'm using two DRS4 rev.5 boards for 8ch readout and triggering.

I needed to modify the trigger logic and implement some tweaks in the firmware, and noticed that 
the firmware source in drs-5.0.2 (and 5.0.3, SVN:5339) while still compiling fine with Xilinx ISE 10, stops
doing so in the ISE 14.7 (also already in 13.2)

While the Synthesis is running through (in the new ISE it complains about using more than 100% of resources.)
The Mapping fails due to constraints (firmware/ucf/drs4_eval5.ucf) complaining about an illegal IOSTANDARD
for P_IO_PMC_USR<55> (LVDS_25).

In the newer version the wild-cards (lines 67..69 ) are not properly dealt with, it seems, and if I move the
property by hand to all the wild-carded NETs it start to recognise the LVDS_25.
But after that Place&Route fails with messages about locked Banks due to incompatible VCCO.

I'm trying to adapt the ucf file and am reading about the changes in the ISE software and constraints files, but
want to ask if some of you guys have seen the same issue and resolved it out "officially".
    Reply  Fri May 22 14:25:45 2015, Stefan Ritt, DRS4 firmware UCF constraints  firmware.zip
> Hello, I'm using two DRS4 rev.5 boards for 8ch readout and triggering.
> 
> I needed to modify the trigger logic and implement some tweaks in the firmware, and noticed that 
> the firmware source in drs-5.0.2 (and 5.0.3, SVN:5339) while still compiling fine with Xilinx ISE 10, stops
> doing so in the ISE 14.7 (also already in 13.2)
> 
> While the Synthesis is running through (in the new ISE it complains about using more than 100% of resources.)
> The Mapping fails due to constraints (firmware/ucf/drs4_eval5.ucf) complaining about an illegal IOSTANDARD
> for P_IO_PMC_USR<55> (LVDS_25).
> 
> In the newer version the wild-cards (lines 67..69 ) are not properly dealt with, it seems, and if I move the
> property by hand to all the wild-carded NETs it start to recognise the LVDS_25.
> But after that Place&Route fails with messages about locked Banks due to incompatible VCCO.
> 
> I'm trying to adapt the ucf file and am reading about the changes in the ISE software and constraints files, but
> want to ask if some of you guys have seen the same issue and resolved it out "officially".

The current firmware compiles nicely under 14.7. I attached it. It also has one modification which you probably need:

When the board triggers, the TRG OUT goes high and stays high until the board has been read out and restarted. So it can be used as a "busy" signal for an external trigger logic.

Best regards,
Stefan
       Reply  Tue May 26 11:27:27 2015, Felix Bachmair, DRS4 firmware UCF constraints  
> > Hello, I'm using two DRS4 rev.5 boards for 8ch readout and triggering.
> > 
> > I needed to modify the trigger logic and implement some tweaks in the firmware, and noticed that 
> > the firmware source in drs-5.0.2 (and 5.0.3, SVN:5339) while still compiling fine with Xilinx ISE 10, stops
> > doing so in the ISE 14.7 (also already in 13.2)
> > 
> > While the Synthesis is running through (in the new ISE it complains about using more than 100% of resources.)
> > The Mapping fails due to constraints (firmware/ucf/drs4_eval5.ucf) complaining about an illegal IOSTANDARD
> > for P_IO_PMC_USR<55> (LVDS_25).
> > 
> > In the newer version the wild-cards (lines 67..69 ) are not properly dealt with, it seems, and if I move the
> > property by hand to all the wild-carded NETs it start to recognise the LVDS_25.
> > But after that Place&Route fails with messages about locked Banks due to incompatible VCCO.
> > 
> > I'm trying to adapt the ucf file and am reading about the changes in the ISE software and constraints files, but
> > want to ask if some of you guys have seen the same issue and resolved it out "officially".
> 
> The current firmware compiles nicely under 14.7. I attached it. It also has one modification which you probably need:
> 
> When the board triggers, the TRG OUT goes high and stays high until the board has been read out and restarted. So it can be used as a "busy" signal for an external t