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.

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

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.

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. 

> 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

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

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

Do the following: 

Use the TRG OUT of the evaluation board as a "busy". Only if this signal goes low (meaning that the readout of the board is complete and the board has been restarted), then re-enable triggers in your trigger logic.

/Stefan

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

Actually we should take this offline not to pester other DRS users which are not interested in this topic. Please call me directly (3728) at PSI.

/Stefan

There is a horizontal position slider in the "Horizontal" box on the right side below the trigger delay. Use it.

Hi Felix,

the distribution does not contain any binaries, since there are too many Linux distributions around, so everybody compiles from the sources under Linux. Do you want me to just add libDRS.so to the official Makefile? Actually you are the first one asking for this. Would it be beneficial to have this in the distribution, or can you just maintain your own Makefile in the github repository?

Stefan

Anyhow it would be nice if you just post your Makefile here, which runs with the standard distribution, so people can use it if needed.

Stefan

> 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

I do not know exactly what you do, so it's hard to give an advice. All I can say that the DRS4 Evaluation Board from PSI allows time measurements between two channels in the order of a few pico seconds. You can download the software for this board from the DRS4 web site and 
have a look how things are done.

The trigger position is not a good time reference, since the trigger position jitters by a few samples. So if you want to measure the time of a signal versus a trigger, you have to put this trigger in a free channel of the DRS4 and use that as a time reference.

Best regards,
Stefan

Have a look here: elog:361

Have a look here elog:434

No idea what you do wrong. I need to see oscilloscope traces for all your inputs and voltages. What is your REFCLK input?

I want to see the trace on the scope for the DTAP, the REFCLK, the DENABLE and the DWRITE.

Probably (but it's just a guess), you have a problem with the soldering of the DRS chip, maybe to the PLL loop filter. Or you chose the wrong capacitor/resistor combination for the loop filter. There are ~10 other groupsl who did the same and it works for all of them, so there must be a problem on your side.

Stefan

Thanks for posting the plots. It really looks like the PLL is not working. I see two possible reasons: 1) The PLLEN bit in the configuration register is not set and 2) The REFCLK signal does not reach the chip. We had cases whrere people had a hard time to solder the DRS4 correctly due to the small pins. So if the REFCLK+ and REFCLK- signals have a poor connection, then the PLL of course won't work. Putting some more tin at the pins manually usually helps. Or remove the chip completely and try with another chip. In theory there is the possibility that the internal bond wire of the REFCLK signal has a bad connection, but we tested all chips we send out so we should have seen that. But trying with another chip cannot hurt in general. Next month I'm coming to the Weizman Institute for the ISOTDAQ shool. If you want we can meet there if you don't mind the 120 km drive from Haifa.

Stefan

While I can understand 1., I'm puzzeled by 2.

If you put the chip in standby mode, the internal current sources are switched off, which of course make the domino wave non-functional. This is clearly stated in the data sheet.

Concerning the DMODE bit, we operate all (!) our chips with DMODE=1. Actually this is the default value. After a reset, all register bits are "1", which enables the PLL and causes DTAP to oscillate. If DMODE=1, the DTAP signal should toggle only once (!) since the domino loop is not closed. So the scope traces you showed previously are consistent with the standby mode, but not possible with ANY setting of DMODE.

Stefan

The 5.0.4 version was corrupt on our server. I fixed it, so now it shoudl also work fine (although there are only very minor changes between 5.0.3 and 5.0.4).

/Stefan