The maximum file size depends on the underlying linux file system. Common values are 4-16 GBytes.

Stefan

Sorry the late reply, I was on vacation. 

Here are some answers:

1. I'm sorry I can't help much here, since I currently don't have a Windows 10 computer here to compile any code. I moved now completely to MacOSX, being very similar to Linux. I'm not allowed to run a Windows 7 computer any more for security reasons. Last time this worked for me was with Wxwidget version 3.0 and libusb 1.0, but I guess libusb is not critical so you can use a newer version. If you just compile drs_exam.cpp, you don't need any Wxwidget library. That one is only used for the oscilloscope program.

2. The program drs_exam_2048.cpp is meant to read channels in 2048-bin mode.

3. To adjust the delay between the trigger and the readout, use the function b->SetTriggerDelayNs(xxx)

Best,
Stefan

The problem must be on your side, since the Write Shift Register readout works in other applications with the DRS4 chip. So I can only speculate what could be wrong:

• Do you really properly set the WSR? When you program it with 00010001b, add 8 more clock cycles and you should see the 00010001b pattern at WSROUT.
• Do all tests with an oscilloscope, to avoid potential problems in your FPGA firmware (like an input configures as an output by mistake).
• DWRITE must be high to see the contents of the WSR at the WSROUT pin, maybe that’s your mistake, see datasheet p 5 of 16.
• To see the contents of the WSR at SROUT, A0-3 must be 1101b, please check with your oscilloscope
• The addresses A0-A3 are simply connected to a multiplexer, so no clock is necessary after the addresses change

Stefan

Hi,

please note the the evaluation board is what it says, a board to evaluate the chip, and is not meant for a full-blown shiny multi-board DAQ channel, so support for that is kind of limited.

Strange that you only find two out of four boards. What happens if you disconnect the two boards the system finds and then try again? Might be that your USB hub does not have enough power to supply four boards (each taking 2.5W, so you need 10W in total). Unplugging some board will show you if you have a power problem.

The drsosc.cfg stores the current configuration. For this to work, the drsosc program has to have write access to the directory where the drsosc.cfg program is stored, which is usually the directory from where the program is started. Maybe you have to adjust permissions. Yes you have commands to set everything, just look into drs_exam.cpp and you will find most of them.

Best,
Stefan

The one thing you can do easily is to look at the scaler values. If one channel counts all physical events, and you have all read out events, then the ratio give you the live/deadtime. The hardware scalers also keep running during the DRS readout.

Stefan

I would say not exactly, but it's a good approximation.

1. Why should your waveform start from 0 to 5ns? I don't get your point. Whenever you trigger a readout, you get a 200ns wide time window, and by definition it starts at zero.

2. In the software distribution you have a drs_exam_2048.cpp program. Note that your board needs to be physically modified before delivery to switch to 2048 bins.

Best,
Stefan

Unfortunately an independent operation from a single computer is not supported by the software. You can try to modify the drs_exam program and extend it. You can poll all boards in sequence and just read out that one which got a trigger, then start the loop again. But I don't know how good you are in programming. I needs a bit of experience to do that.

Stefan

I'm not sure if the rate would go up to 2 kHz (not 2 GHz!). Depends how the USB hub is designed. What you can do however is to buy 4 RaspberryPis (total cost 150$) and run everythign in parallel. The evaluation boards works nicely with the Pi's.

A V3 boards is already 10 years old and out of warranty. The software has no configuration to turn channels off except the channel buttons on the main page on top of the sliders. I presume the channels are broked due to some overvoltage applied to them (the V5 board is better protected against over voltage). You can send it the board for repair, but it will cost almost the same amount of money than buying a new boards.

Regards,
Stefan

Hi,

I wish to interface the DRS4 with the 8-channel ADC AD9222 (or AD9637).

I'm reading from the DRS4 datasheet that "the analog output of the DRS4 chip has been designed to match directly the input of the AD9222". OUT+ output of DRS4 is in the range from 0.8V to 1.8V and OUT- output is shifted by the voltage applied to the O-OFS pin.

The span of the AD9222 ADC core is defined by REFT and REFB which are resp. 1.4V and 0.4V in a typical case (AVDD=1.8V, VREF=1V). My understanding is that the ADC analog inputs must be within the voltage range defined by REFT and REFB and so I don't quite see how this matches the DRS4 outputs.

Can we use the full-scale range indeed? Do we have to use AC-coupling with mid-supply bias? What is the point I missed?

Thank you for your help.

Hi,

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.

Thank you.

Stephane

 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?

Thank you.

Stephane

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.

It works as expected.

Thanks for the help.

I'm not doing this for fun, checking that the source matches the .iic ! I know I could directly use the .iic and forget about the hex and c files.

I just wanted to use your source file as the starting point for my own board, as everybody is doing at the application level.

Hello All,

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. 

Best,

Steven

Hello All,

I am currently trying to figure out how to properly characterize the dead time of the DRS4 board. My most recent experiment to try and answer this question involved using an external trigger that can range from 1Hz to 2MHz. I fed this trigger into the DRS4 and collected 1000 samples with no input to any channels. I repeated this across the range of my external trigger by a factor of ten [10Hz, 100Hz, 1kHz...etc]. After I had saved these runs in XML format, I looked at the difference between timestamps on the events. Attached are my findings. Can someone offer an explanation for the periodic peaks? I am new to the DRS4 and don't really understand how it works. My guess is that there is a buffer that has to be emptied every so often, but if so, the buffer emptying time varies with the frequency of the trigger. I would ideally like to be able to know the relation of the dead time to a particular setting I change on the DRS4 such as locking the sampling speed or changing external trigger frequency. 

Best,

Steven

That is extremely helpful! Many thanks. One more question; If I were to take inputs from 2 channels at once, would that scale the dead time to 64us using your example? 

Steven

Hello,

I have a question about how ROI works. From what I have read, it will only save data that ocurs some time [t_a] dictated by the user after an event is triggered as well as a small time [t_b] before the event. The technical manual seems to indicated that the deadtime assciated with operating in ROI mode can be reduced by the following factor: 

.

Where N is the number of points in the time window (ex. 2048 or 1024). Is it ok to describe this as:

Where N' is the number of samples in the ROI and N is the same as before.

For example, if I were running at 5Gsps (200ps between samples), only recording 1024 samples per event and I had an signal that lasted 2ns, that means the signal would last 10 samples. If I set the ROI to only save 20 samples around this signal, would my Deadtime go to:

? (The second portion of this equation comes from a response I recieved earlier, but I just want to make sure I understand this concept properly)

I recognize that the caveat is that this would work only if the signal was detected during acquistion, which leads to my next question. If no signals were detected in the 1024*200ps time frame in ROI mode, would the DRS4 go dead for 32us (using the factor = 1 from above equation), or would it dump the earliest events in the buffer for the more recent ones until it detects a signal? 

Finally, I assume this functionality can only be utilized with custom electornics with the DRS4, not the evaulation/demo board, please let me know if this is the case. 

Best,

Steven