I have a machine with Windows 10 and the solution provided by Steven works fine. To give more details, the driver installed in my case is WinUSB (i.e. libusb, v6.1.7600.16385).
Thank you for this fantastic solution. I had almost reinstalled windows 7 to see if that would solve the issue!
All the best,
Dear Steven, many thanks for this information, this is very useful. I know of people having problems on Windows 10, maybe this will also help them.
I too have been struggling with trying to get the drs4 (507) to work on my windows machine and I found it to be a problem with the libusb library. My solution is as follows and has worked on multiple PC's. I ran this solution after I first plugged in the drs4 and installed 507.
Go to http://zadig.akeo.ie/ and install the corresponding software.
After that, you will need to plug in the DRS4 to your computer. From there go to ‘Options’, and select ‘List all Devices’.
Finally, choose the DRS4 evaluation board from the list and press install driver and let it run. You should be fine after that.
we were trying to implement an automatic way to calibrate our DRS4 both in voltage and in time (we have the V5 Evaluation Board). We started from drs_exam.cpp and tried with the following lines:
/* set input range to -0.5V ... +0.5V */
While the timing calibration seems to work (we checked with drsosc executable), the voltage calibration in our test program seems not to do the same as in drsosc when pressing the button "Execute Voltage Calibration". Specifically we think that no primary calibration, secondary calibration or spike removal is applied when calling CalibrateVolt(). It seems that the methods to perform those tasks are implemented in Osci.ccp/Osci.h, but drs_exam.cpp uses objects of the class DRS (i.e. defined in DRS.cpp and DRS.h).
Is there a way to execute the voltage calibration in drs_exam.cpp in the same way performed within drsosc?
Have you set the sampling frequency
before the calibration?
Note there is also the "drscl" program, which is a ocmmand linke interface to the evaluation board. Start it, and do the calibration there:
then look at the code in drscl.cpp (around line 1097).
It turned out that the VDD switch off speed plays some important role. On our VME board, we have a linear regulator, then a 4.7 uF capacitor, then the DRS4 chip (DVDD and AVDD). When switching off the VME power, it takes quite some time to discharge the 4.7 uF capacitor, since the DRS4 chip goes into a high impedance mode if VDD < ~1V. This gives following VDD trace:
Rising edge is power on, falling edge is power off. Note the horizontal time scale of 2 s/div. So to get below 0.3 V or so, it takes up to 30 seconds. If the power is switched back on when AVDD is above 0.3V, the DRS4 chip can get into a weird state, where probably many domino waves are started and the chip draws an enormous amount of current. Typically the linear regulator limits the current, so the 2.5V drops to ~1.5V, and the board is not working. If people are aware of this and always wait >30sec. before turning the power on again, this is fine, but people might forget.
So the solution is to put a resistor (typically 100 Ohm to 1 kOhm) parallel to the 4.7 uF capacitor in order to have some resistive current load of a few mA. The discharge then looks like this:
Note the horizontal scale of 10ms/div. So after 30 ms AVDD is discharged and powering on the chip again does not do any harm. The same should be done to DVDD.
It has turned out that the stability of the AVDD and DVDD power supplies for the DRS4 are very critical. On the evaluation board I use a REG1117-2.5, on our VME board I use a ADP3338-2.5 for the DVDD power supply. When the domino wave is started, the power consumption of the DRS4 chip jumps up by ~40 mA, which has to be compensated by the linear regulator. Following screen shot shows what happens:
The blue trace is the DWRITE signal indicating the sampling phase when high. The yellow is the SRCLK showing when the readout takes place. The pink is now the DVDD power. It can be clearly seen that there is a dip of ~50 mV when the domino wave starts, a positive dip when it stops and another smaller dip when the readout starts. This causes strange effects: If the trigger arrives during the first dip, the actual sampling takes place when the DVDD is ~50 mV smaller, which leads to a baseline shift of a sampled 0V DC input voltage of about the same amount (-50 mV).
The obvious improvement is to put a huge capacitor on the power supply, but that does not help much:
The dip gets a bit smaller, but it's still there. So a better solution would be to use a faster LDO regulator. Please take care of this if you plan a new design.
Furthermore, I believe that the chip internally has some "warmup" phase, where the die heats up a bit when the additional 40 mA are drawn. So a "good" solution is to wait some time after starting the domino wave until one allows for triggers. Tests showed that a few milliseconds are necessary to keep the baseline shifts below a few millivolts. This of course decreases the dead time of the system significantly, so one has to choose the proper balance between increase dead time and increased base line shift. On some applications where a baseline shift is not an issue, one could opt for the minimum dead time.
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,
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...
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.
I had forgotten to disable the turn off the power to the USB drive on Windows and DRS4 stopped triggering. Now, we are all on quarantine and I am unable to reset the board to normal function. Are there any commands to reset the board remotely. I tried all of the default Windows based solutions such as disable USB port etc., but I am unable to do this. Only thing that has worked in the past is manually replugging the USB but I do not have the option to do that currently. Please help.
Hello the DRS4 team,
I and some of my colleagues are using DRS4 evaluation boards (ver. 3) for the R&D of the Cherenkov Telescope Array project. During
our PMT measurements, we have encountered a problem which is probably related to USB connection. In fact, I cannot reproduce this
problem with my Linux virtual machine (Scientific Linux 5 64 bit), but other colleagues from three different universities in Japan
reported the same problem with their real machines.
=== Short Summary ===
DRSBoard::SetFrequency occasionally stops
=== Environment ===
- Scientific Linux 5.5 (32 bit)
=== Steps to Reproduce the Problem ===
1. Compile the attached file drs_simple.cpp with drs-3.0.0
2. Repeat the following command several times from a terminal
$ drs_simple -0.05 1000 ./outputfilename.dat true 2.
3. The above command may stop. In that case, you need to kill the command by Ctrl-C.
=== Comments ===
- Once the command stops, we cannot run the above command properly.
- If we unplug and plug the USB cable again, the command can be executed again.
- It seems that the program stops inside DRSBoard::SetFrequency
I would very appreciate it if you could give me any advise. If you need further information, please let me know.
although I don't have a chance to test your code, it looks very similar to what I am using.
I can confirm that the DRS4 communication breaks down if the program talking to the DRS4 is closed abruptly or before is has a chance
to properly execute "delete drs" where it closes the USB connection.
For me if I terminate the program that's using DRS4, the next time I might or might not be able to connect to the DRS4 because I would
get a magic number or the program would just stop. The DRS4 eval board needs to be restarted via pulling the plug if the orange LED is
I have tried to power down the DRS4 board via software under SL6 linux, but the reality is that the DRS4 eval board is powered directly
by the 5V USB rail off the computer, and you cannot software control that, you can only suspend the communication of the USB
So I don't have a solution to fix this issue, but my best advice is to change your software such that it calls "delete drs" to
terminate the USB connection before you close or terminate the program.
Oh and I have not tried running multiple programs at the same time to see if that might be causing the issue as well. The usb library
might simply error out saying the device is inaccessible because it's being used.
> Hello the DRS4 team,
> I and some of my colleagues are using DRS4 evaluation boards (ver. 3) for the R&D of the Cherenkov Telescope Array project. During
> our PMT measurements, we have encountered a problem which is probably related to USB connection. In fact, I cannot reproduce this
> problem with my Linux virtual machine (Scientific Linux 5 64 bit), but other colleagues from three different universities in Japan
> reported the same problem with their real machines.
> === Short Summary ===
> DRSBoard::SetFrequency occasionally stops
> === Environment ===
> - drs-3.0.0
> - Scientific Linux 5.5 (32 bit)
> - lib-usb-devel-0.1.12-5.1.i386
> === Steps to Reproduce the Problem ===
> 1. Compile the attached file drs_simple.cpp with drs-3.0.0
> 2. Repeat the following command several times from a terminal
> $ drs_simple -0.05 1000 ./outputfilename.dat true 2.
> 3. The above command may stop. In that case, you need to kill the command by Ctrl-C.
> === Comments ===
> - Once the command stops, we cannot run the above command properly.
> - If we unplug and plug the USB cable again, the command can be executed again.
> - It seems that the program stops inside DRSBoard::SetFrequency
> I would very appreciate it if you could give me any advise. If you need further information, please let me know.
Thank you for your advise. But we never terminated the program before closing and deleting the DRS object. What we did was just executing the program multiple times
finally I found some time to look into this problem, sorry for the late delay.
I tried your program and started it maybe 50 times without an issue. So I cannot reproduce your problem.
I know that if you do Ctrl-C then you might have some data "stuck" in the USB interface, like you ask for a
waveform data buffer but you never read it because you got interrupted by the Ctrl-C. But when you reinitialize
the board the next time, all stuck data is drained before the board is initialized. This is done in DRS.cpp
around line 343:
/* drain any data from Cy7C68013 FIFO if FPGA startup caused erratic write */
i = musb_read(usb_interface, 8, buffer, sizeof(buffer), 100);
if (i > 0)
printf("%d bytes stuck in buffer\n", i);
} while (i > 0);
So occasionally, after a restart after a Ctrl-C, you will see "xxx bytes stuck in buffer", but then the boards
should come up correctly.
If you have the problem without Ctrl-C, then maybe your specific board has a hardware problem? Do you have
access to another board?
I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.
I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.
Thank you Stefan.
Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?
There is only one drs_eval.c version around, and I confirm that it is the one in the distribution. If you use different compiler settings, like optimisations, you might get a different executable file (and thus a .iic file), but the files have the same functionality.
I'm very sorry to insist but if I take the .hex of the distribution, convert it to .iic using the hex2bix utility, and reprogram the board, I can't read the board correctly (invalid magic number read with drscl for instance). Also, when using the uVision2 project file you provide and compiling the drs_eval.c, I get the same result (i.e. no way to generate a functional .iic file starting from the sources). So, either I'm doing something wrong (and I don't know what) or the drs_eval.c is not the correct one.
And what happens if you program the .iic file from the distribution?