Thanks for the update, I will add a note into the data sheet.

surrey i forgot to update..

after carefully examining our VHDL we found out that there are brief times that we put A0-A3 in 1111

after making shore that a0-a3 never get 1111 value thae drs4 woks as expected.

The dtap toggols ok.

We can sample and read all the data channels.

So, putting A0-A3 value of 1111 even for very short period  " confuse " the DRS and then it start to behave in a strange manner.

mony

I guess you are compiling under MS Windows ??? You probably don't link correctly to the USB lib. Try to compile the examples coming with libusb-1.0 to make you everything is right there.

I am trying to compile drs-exam, but am getting an error message I do not understand:

1>musbstd.obj : error LNK2019: unresolved external symbol _usb_open referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_close referenced in function _musb_close
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_get_descriptor referenced in function _musb_get_device
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_set_configuration referenced in function _musb_open
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_release_interface referenced in function _musb_close
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_reset referenced in function _musb_reset
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_debug 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_find_devices referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_get_busses referenced in function _musb_open

I have tried redownloading a different version of libusb-1.0, but the problem was not solved.  What might I be doing wrong?

Hi Larry,

sorry my late reply, swamped with work here. You were right in the modifictions you did, congrats. The speed limitation of 500 events come from USB2, which simply is not fast enough. The 500 Hz are mentioned on the evaluation board web site, so you should have seen that before ordering. Some people build their own hardware around the chip, in which case they get higher rates. The "hard" limit is the DRS4 readout speed, which is 30ns per sample. So if you have 8 ADCs in parallel, and you only need 100 samples of your waveform, the readout time is 3 us, in which case you could go up to a few 10 kHz without much of a dead time.

Cheers,
Stefan

An update. I have been successful in making modifications to drs_exam.cpp so that I can get 2048 samples per channel.. The main changes were to the size of the time_array and wave_array and adding a call to Set ChannelConfig(0,8,4). It was also necessary to change the parameters to GetWave so that the Trigger Cell and WSR values were passed to get the channel combinations correct (2048 channel.ppt).

I've moved on to try to increase the speed of acquisition (I get only about 500 events/sec) and trying to understand the corrections.Working through the source code slowly...

Regards,

Larry Byars

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

Hello Stefan,

Here in Rockford, TN we just got a new DRS4 evaluation board (Serail # 2612, Board Type 9, Firmware 21305) which is labeled as combined 2048.

It looks like the drs_exam.cpp only works with 1024 samples per channel. We'd like to be able to get 2048 samples from each of the four channels but I am uncertain what code modifications are necessary support this.

Could you offer a suggestion? I've searched the forum for cascade and read several threads but they are pretty old. One even says it isn't supported in the evaluation board, but I think that is no longer the case.

Thanks for your help,

Larry Byars

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

Hi

We have resolve the problem, the Dtap is now working correctly.

There were two problems:

1. After configuration we put the all address bits to one (standby mode)

We are now setting the address bits to all zero. Failure

to do so result in Dtap  stop toggling after several hundred milliseconds.

1. The DMODE bit in contradiction to the data sheet should be set to 0

And not to 1.

Is this a known bug in the chip?

Only bay setting DMODE to zero we got the Dtap to work correctly.

The PLL locks after 1 milisec.

If we set it to one we get Dtap that stop toggling after several hundred milliseconds.

We have test it on two boards, they both worked in the same.

Never did we get a One shot  Dtap.

Did you published a errata page to the drs4?

Thanks, Mony

Hi Stefan

Thanks for your input.

We are in the process of assemble another PCB board.

so soon we can compere between two boards.

As for the PLLEN bit, we set it.

We checked several times the soldering of the DRS4 using a microscope.

Everything looks ok.

In what method do you recommend to solder the DRS4?

Thanks for the invitation to meet.

120Km is not so far J

mony

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

Hi

We have some measures to show (attached)

1. Dtap and Denable
2. Dtap+Denable in zoom
3. Dtap + Refck+
4. Dtap + Dspeed

From the screen shots it can be seen that refck+ is not synchronized with Dtap (PLL not working correctly)

And Dspeed is going done to zero after some time.

In our system Dspeed is shorted to pllout.

So it looks like pllout do not pump the RC filter capacitors.

We tested various value of R and C's.

Also we checked that pllout is sorted to Dspeed.

Thanks, mony

Hi

We have some meesurs to show (attached)

1. Dtap and Denable
2. Dtap+Denable in zoom
3. Dtap + Ref+
4. Dtap + Dspeed

From the screen shots it can be seen that ref+ is not synchronized with Dtap (PLL not working correctly)

And Dspeed is going done to zero after some time.

In our system Dspeed is shorted to pllout.

So it looks like pllout do not pump the RC filter capacitors.

We tested various value of R and C's.

Also we checked that pllout is sorted to Dspeed.

Thanks, mony

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

my refclk is 1.25Mhz

what are the inputs and voltage you need to see?

Avdd and Dvdd are 2.5v

Denable is "1" Dwrite "0"

currently i am doing an external reset cycle, after that i am doing the configuration cycle.

should i relay on the internal reset?

the Dtap is toggling for 33.8msec and then just stops.

Thanks, Mony 

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

Hi

the drs4 start to generate Dtap signal after reset and standard configuration.

while in reset Denable and  Dwrite are low

after reset we put Denable in high

the Dtap starts to toggle, and the plllck stabilizes on about 1V.  

After 40Msec the Dtap stops to toggle and the plllck go to 2.5V

Why do the Domino stop working?

Thanks, Mony

On a hunch, I tried downloading V 5.0.3 instead. This works, and I now have the oscilloscope mode displaying signals! (just to make sure, I re-tire version 5.0.4 and still get the same error. So, in summary V 5.0.3 seems to install successfully and work with Windows 10, but the newer V5.0.4 does not install... I assmume that I am missing something though, as the newer version is 10 Mbytes bigger!

I tried restarting Windows 10 in a way the allowed me to use "advanced startup options" Option 7 suggested it was to restart without mandatory driver signing. However, the error persists. Has anyone tested this latest version 5.0.4 on Windows 10? My hardware arrived today, and I am anxious to test it.!!!!