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.

Hello,

is it possible to set a completely negative input range like -1 to 0 or -0.95 to 0.05 ?

See elog:531

Thank you

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!

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?

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.

Hi. I'm trying to evaluate livetime of the evaluation board with the hardware scaler. I'm facing a strange issue.

I took the rate with the function, DRS->GetScaler(int channel).
I guess that channels 0--3 mean the rate for the channel, and channel 4 means the counter of the trigger.
I took the 1,000 pulses generated by a pulse generator with 50 Hz.
The scaler values are ~ 39.83, not 50.
The timestamp difference between the initial event and the final event is 19.98 seconds.
1000/19.98 ~ 50, thus, the evaluation board took the pulses with enough livetime.

Can we believe the scaler value for the livetime evaluation?

The scalers are read out 10x per seconds, so they have an accuracy of 10 Hz. I tried a 50 Hz pulser, and measured 40 Hz, I tried 52 Hz and measured 50 Hz. This is about what you can expect.

The scaler rate is measured after the discriminator of the trigger, so the trigger level also affects the scaler reading. If you have a 100 mV pulse and your threshold is 200 mV, your scaler rate drops to zero. That can be seen best with the DRSOsc and sliding the trigger value. If you have a 50 Hz pulse with narrow (< us) pulses, things are fine. But if you use a 50 Hz square wave, then you get distorted signals due to the AC coupling which can also be confusing. See for example here: https://www.daqarta.com/dw_gg0o.htm

Thank you very much for your explanation.

I would like to show you a pulse example ('black line is the threshold).

Still, pulse generator rate and DRS4 rate are a bit different more than 10 Hz.

I tried your measurement with the DRSOscilloscope app (see below), and I measure a constant difference of 10 Hz among the whole range of 100 Hz to 3 kHz.

So I don't know what's wrong on your side. Did you try with the oscilloscope app as well? Have you checked your pulse generator? The evaluation board time reference is a quartz with an accuracy of 10^-5, so no way one can get there a difference you see.

Stefan

Hello,

We want to use the inner DRS4 counter(scaler) within more than the 100ms integration time. We guess that we need to modify the original firmware around this point:

-- Reference clock used for frequency counter
 
  proc_1hzclk: process(I_RESET, I_CLK33)
  begin
    if (I_RESET = '1') then
      drs_1hz_counter(31 downto 0)          <= (others => '0');
        drs_1hz_clock                         <= '0';
        scaler_reset                          <= (others => '1');
        scaler_ff_reset                       <= (others => '1');
    elsif rising_edge(I_CLK33) then
      drs_1hz_counter                       <= drs_1hz_counter - 1; -- count down
        scaler_reset                          <= (others => '0');
        scaler_ff_reset                       <= (others => '0');
      
      -- toggle refclk if timer expires      
      if (drs_1hz_counter(drs_1hz_counter'high) = '1') then
        drs_1hz_clock                       <= not drs_1hz_clock;
        drs_1hz_counter(31 downto 0)        <= X"0016E35F";     -- 1499999, I_CLK33 is actually a 30 MHz clock
          
          scaler_ff_reset                     <= (others => '1'); -- reset scaler_ff once every 100ms cycle
        loop_scaler_reset : for i in 0 to 5 loop
          if (scaler_ff(i) = '0') then                          -- no activity since last cycle?     
               scaler_reset(i)                <= '1';             -- force clear scaler register
            end if;
        end loop;

          if (scaler_ff(0) = '0') then                            -- no activity since last cycle?     
            scaler_reset(0)                   <= '1';             -- force clear scaler register
          end if;
          
      end if;  
    end if;
  end process;

Could you please tell us how to modify the firmware to increse the time up to 5 seconds for instance?

Thanks in advance, Arseny

I would really love to be able to save histogram data, though I have not been able to do this. I could take a screenshot and extract the data from an image, but would prefer to avoid this if there is a simpler way... possibly I have overlooked something obvious? Thanks very much for any advice or tips.

There is no histogram save functoinality in ther DRSOscilloscope program - on purpose. The board and the software are meant to evaluate the board, not to replace a full DAQ system. If we want to save histograms, you maybe also want to set the range, make cuts, do fits etc. So it would take lots of resources to add all that. Therefore we recommend to use the stand-alone C program drs_exam.cpp to read the board, the you can either do whatever you want in the C program, including saving of histograms. Alternatively, you can use ROOT to analyze binary stored DRS data and do whatever histogram manipulation you want there.

Stefan

You can use qtpals, there is posibility to save histograms (energy, time diference), only set trigger on channel which you use. https://sourceforge.net/projects/qtpals/files/?source=navbar

Dear All,

when I use my Evaluation Board with some PMTs I can digitize 450 Acq/s or so. But when I want to save the waveforms the rate goes down. The Acqu. rate with saving is in the range of 14Hz up to 24 Hz.

I normally use the .txt file. I try to use the 5GS/s but also with much lower sampling rate the saving rate is not getting much better. 

Is this a problem of my McBook connected to the Evaluation Board?

All the best,

Hans 

The reduction of rate is because you save in XML format, which is an ASCII format, so human readable, but takes long to write. If you switch to binary format and write on a decent fast hard disk, you should get back to 450 Acq/s.

Stefan

 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

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