hi Stefan,can you update the code to convert binary to root for newest drsosc?Thanks.

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

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.

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.

Yes. I use exactly the same scheme as you mentioned. I'll try your solution.

If using a ROFS of 0.9V, the input would not between 1.05V~2.05V better non-linearity area. Is that appropriate?

Hi,
  I have a question using a data acquisition card base on DRS4 chip. How can I measure the time between several samples of one channel，with the accuracy of like nanoseconds , for I am using the internal trigger. Is there any complete work about this problem？
  One conceivable way is using an global counter in FPGA, but I'm wondering how to synch the counter with the DRS4 sampling.
  Thanks.
Chenfei Yang

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\

 Hi Stefan,

you were right, I forgot to install the libusb driver.

Thanks for your support

Hello, 

I have recently obtained a DRS4 Evaluation Board (V5), but I am unable to register signals when using the DRS Oscilloscope application. There seems to be some difference in noise when I have an input connected to a signal or not, but I am unable to view a simple, 0.2V amplitude square wave or other small signals. The only way I have been able to view a waveform is when connecting the reference clock to all channels. When running 'info' in the DRS Command Line Interface I am shown correct information. I was wondering if there is any way for me to test the functionality of the board (specifially ability to read signals on Ch 1-4) to ensure that it is indeed working as expected? 

Thanks, 

Brendan

Hello Stefan, 

Thanks for the quick reply. The issue was a faulty SMA connector, should have checked this first. Signal looks good now.

Thanks for your time, 

Brendan

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?";
 

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 Stefan,

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

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

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

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

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

Many thanks,

Bill

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

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

Thanks again,

Bill

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!
 

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

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

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

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