Hi Stefan,
No we only use one evaluation board. We use the evaluation board as a part of our beam test setup. It includes a telescope based on the current PSI46V2.1 CMS Pixel chip and a trigger logic board for triggering the telescope and the evaluation board. This includes a 
handshake between every device and the tlu
e.g. the tlu expects an answer for each trigger.
If the trigger comes within this first 200 mus it seems that not every trigger is accepted.
In this moment our readout would 'die' since the tlu is waiting for the handshake.
Cheers
Felix

> I presume you have several evaluation boards and want to run them in sync, right?
> 
> This can be either made in daisy-chain mode (see manual page 25). In this case only the master board can trigger the slave boards. If you need to trigger on SEVERAL boards (like a coincidence between two boards), you have to do this with an external trigger and 
busy logic. This is rather 
> complicated and needs detailed explanations. So come to my office and I will teach you.
> 
> Best,
> Stefan

I presume you have several evaluation boards and want to run them in sync, right?

This can be either made in daisy-chain mode (see manual page 25). In this case only the master board can trigger the slave boards. If you need to trigger on SEVERAL boards (like a coincidence between two boards), you have to do this with an external trigger and busy logic. This is rather 
complicated and needs detailed explanations. So come to my office and I will teach you.

Best,
Stefan

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

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

Hi Stefan,
Thanks a lot for the new firmware. We are testing it at the moment in a beam test at PSI (PiM1) and we realized that this doesn't seem to work 100%.
We need to extend the death time after a trigger by approx. 200 mus in order to not loose triggers.
It seems that under certain circumstances a trigger within that window is ignored. 
We do a handshake after each trigger so we are able to recognize such ignored events. This can happen quite often (within the first few hundered events) when we do not increase the deadtime.
Do you have any idea what could be the reason for that issue?
Best regardds
Felix 

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

Hi

We are working with the DRS 4 V5 version and we investigated an issue with the trigger at rates below ~120 Hz.

As long as we have a trigger rate of more than 125 Hz. everything seems to work fine and we are recording more or less all events.

As soon as we go lower in input trigger rate to 100Hz, we see a drop in trigger rates to approx 15 - 20 Hz.

When we use the new firmware we can see that the busy signal is  0 for much longer times than usual up to .5 seconds.

We made a plot of input trigger rate vs trigger rate of drs: https://plot.ly/~simon.corrodi/316

In the  oscilloscope plots one can see the the trigger in in yellow and the trig out from drs board in blue.

Do you have any idea what could be the reason?

We also

> 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

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".

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. 

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

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

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.

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.

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...

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.

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.

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

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.

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?

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