The maximum file size depends on the underlying linux file system. Common values are 4-16 GBytes.
I have been collecting some date using the DRS4 board at a trigger rate of 10-20 Hz, I only need the timestamp and the amplitude, is there anyway to select only these two live as the data comes in to be stored.
Alternatively, What's the maximum file size or maximum number of events I can store in one binary file in linux.
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)
Recently I bought a 5GSPS evaluation board with 2048 sampling points.
I want to read 4 inputs of the evaluation bord ar 5 GSPS or 2.5GSP and use an external trigger.
I've checked your website and download drs-5.0.5 which contains the source code in C. It seems that the file drs_exam.cpp can do what I am looking for.
So far I could make and compile the project in Linux Ubuntu, but I couldn't compile it in Windows 10. I've used Cygwin64 to compile the project in windows 10.
I have the following questions:
1- Since I only need to compile the drs_exam.cpp file, could please help me with how can I compile it directly(without making the entire project). Or tell me which version of Wxwidget and libusb I have to install.
2- If you have any sample code that can read 4 inputs with an external trigger, please tell me where can I find it.
In the end, I want to write a wrapper on this C file(which returns digitized data) and run it from my python program. Thank you in advance.
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:
I have a question about how to acquire the stop channel:
Process: Configure the Write Shift Register with 00010001b to achieve 4-channel cascading, then after a trigger, set A3-A0 to 1101, sclk keeps 0.
Result: the WSROUT pin keeps 0, the SROUT pin has no clock pulse as written in datasheet, but keeps always 1 or 0. It can be seen the stop channel is channel 0 or channel 1, but no situation to represtent channel 3 or channel 4. And if set sclk with 8 pulses, the WSROUT and SROUT both keep 0.
What should I pay attention to? Looking forward to your reply.
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.
I made a modified version drs_exam_multi.cpp, but ran into an issue when running. When I ran it, it only found the two boards with lower serial numbers (2781 and 2879) and complained that the others (2880 and 2881) were not v4. Would there be a simple workaround for this type of thing? Also, would I be able to use the .dat format to keep the file sizes down.
If not, I am curious if there is a way I can at least set a default configuration for the drsosc program. It seems the drsosc.cfg is written when drsosc starts? Does it load the configuration from somewhere else? It would be very helpful to keep the same settings between runs, in particular the trigger delays, levels, trigger mode, and voltage offsets. Maybe I can even do this with just a few of the CLI commands? I know this is for experts only, but I think I would just need a few commands (setTrig, setTrigMode, setTrigDelay, that sort of thing) if they do exist. I would check the help now, but I'm running, and I'm pretty sure I saw some for trigger settings.
Anyhow, any help is appreciated in creating a more repeatable and automated data acquisition. Thanks!
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.
I would like to use the DRS4 evaluation board for actual physics experiment.
I made a CUI script based on the drs_exam, https://github.com/mzks/drs4_tools/blob/main/build/source/drscmd.cpp.
In this framework, how can we obtain DAQ livetime (or deadtime)?
Has some function already provided to evaluate them from firmware?
I would say not exactly, but it's a good approximation.
Thank you very much for your response.
Excuse me for my very stupid confirmation.
If I take N events finally and the hardware scaler value is M, the livetime is realtime*(N/M). Is this correct
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.
I have two problems regarding using the drs_exam file with external trigger:
1- I connected a 200Khz signal with 20ns rising edge, 50 ohm load, and 27% duty cycle as an external trigger. The output of the drs_exam file starts from 0 to 200ns. Since I use an external trigger, I think it should be starting from 0 to 5ns and then again starting from 0. Could you please tell me where the problem is?
2- How is it possible to change from 1024 to 2048 bins in the drs_exam example?
You can find my code in the attachment.
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.
I recently acquired 4 DRS4 boards and I wanted to ask if it was possible to trigger them independently from the same computer.
I know that you can daisy-chain boards and trigger them all at the same time, but in my case, each of my boards record independent events, so I want them to trigger when trigger conditions are met in each board. I currently use the provided DRSOSC software, that can trigger on only the board that is being displayed at that moment. I tried opening several instances of DRSOSC to associate each to each board, but that is not possible since the second instance already does not find the boards. I wonder if there is a way of triggering from each board independently without having to use four computers.
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 related question is: if the 4 boards are triggering at max rate (500Hz), would the total data throughtput (of the four boards together) be 2GHz (500Hz x 4)? Or is the limitation on the readout, rather than the triggering?
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.
I'm still looking through the forum for an answer to this question, but thought I'd go ahead and post anyway just in case it hasn't been answered yet. If it has I can take this post down.
I have a V3 board, and as far as I can tell only channel 2 gives an output. If I enable other channels using the DRS Oscilloscope software, they do show static but will not show a signal if I connect one to them (e.g. a series of subsequent square waves). A technician and I took the board out and tested all the components leading up to the microcontrollers for each channel, and everything seemed to be working fine. I thought maybe it was configured to only have one channel read an output, but I looked through the Config panel in the software and nothing seemed to indicate that.
I am a novice, and maybe I'm missing something that I didn't see in the manual. I can post screenshots if needed!
Thank you for your help!
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.
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?
It works as expected.
Then why don't you use the .iic file and forget about the hex and c files? Honestly speaking, I don't remember what source file I compiled a couple of years ago, and it could be that an older file slipped into the repository, but that's all I have. I would have to investigate myself, try to compile and program the c file, do the debugging, and find out what the differences are. But unfortunately I don't have time for that right now. So just stick with the .iic file.
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.
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.
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.
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?
XML is very slow to write, and you are probably limited by that. Switch to binary mode, which is much faster. You will see in the end a maximum rate of ~500 Hz, and thus a dead time of 2ms, independent of the sampling speed. Note that you have only an evaluation board, which is optimized for ease of use. If you develop your own electronics, and do optimized readout, you can bring the deadtime down to 30ns x number of samples + 2us, or 32us if you read 1024 values from one channel.
I have a question about how ROI works. From what I have read, it will only save data that ocurs some time [ta] dictated by the user after an event is triggered as well as a small time [tb] 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.