Thank you for your fast and very helpful replay.
I made it work with drsosc version 4 but with version 5 i am getting weird results. Is it possible that they changed binary formatting?
Yes, but this is documented in the evaluation board manual. You have to modify the script slightly. I will update it myself in about 2-3 weeks.
hi Stefan,can you update the code to convert binary to root for newest drsosc?Thanks.
Hello Mr. Stefan Ritt
For DRS4 differential inputs ranges form 500mV to 1100mV, with ROFS set to 1.55V, O_OFS set to 1.3V, the outputs of DRS4 is shown in the attachment.
The left part of the waveform,DRS4 works in transparent mode, and then the readout take place. The DMV of transparent mode is bigger then the readout mode, and that makes ADC sampling harder.How may I solve this problem?
Here's the problem. My external ADC has 2Vpp differtial input voltage range. And the common-mode voltage of the inputs need to be 1.3V. I cannot make both the transparent-output and the readout-output meet the ADC input requirement.
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'm using an AD9252, 0.9V common mode voltage is suggested and I already use 8 un-switchable level shifters. Just as you said, this common mode range is recommended for optimum performance and the device can function over a wider range with reasonable performance. So I think I could adjust O_OFS to a minor level during transparent output.
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...
Yes. I use exactly the same scheme as you mentioned. I'll try your solution.
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.
If using a ROFS of 0.9V, the input would not between 1.05V~2.05V better non-linearity area. Is that appropriate?
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.
when I try to compile drs_exam project my computer give me this output:
1>------ Rebuild All started: Project: drs_exam, Configuration: Debug Win32 ------
1>------ Rebuild All started: Project: drs_exam, Configuration: Debug Win32 ------
Have a look at the web site http://www.psi.ch/drs/software-download . Under the MS Windows section it says that you have to install the libusb-1.0 package first before you can compile the example program. This is also obvious from the missing _usb_* functions in the error listing above.
you were right, I forgot to install the libusb driver.
Thanks for your support
I have recently obtained a DRS4 Evaluation Board (V5), but I am unable to register signals when using the DRS Oscilloscope application. There seems to be some difference in noise when I have an input connected to a signal or not, but I am unable to view a simple, 0.2V amplitude square wave or other small signals. The only way I have been able to view a waveform is when connecting the reference clock to all channels. When running 'info' in the DRS Command Line Interface I am shown correct information. I was wondering if there is any way for me to test the functionality of the board (specifially ability to read signals on Ch 1-4) to ensure that it is indeed working as expected?
Thanks for the quick reply. The issue was a faulty SMA connector, should have checked this first. Signal looks good now.
Thanks for your time,
Have you set the trigger correctly to the channel with your signal, polarity and level? Do you undersand the difference between normal and auto trigger? Why don't you post a screendump. Are you ABSOLUTELY SURE that you have a signal on your cable? Have you tried with another oscilloscope? Are you sure that your SMA connector is good?
I was just building version 3.1.0 and ran into some problems in DOScreen.cpp. Basically the conversions from
char* to wxString were generating "ambiguous overload" errors (in gcc 4.4.3, wx-2.8)
The simple fix is given in the following diff output.
diff drs-3.1.0_o/src/DOScreen.cpp drs-3.1.0/src
< wxst = wxString(m_frame->GetOsci()->GetDebugMsg(),wxConvUTF8); //BH
> wxst = m_frame->GetOsci()->GetDebugMsg();
< wxst = wxString(m_debugMsg,wxConvUTF8); //BH
> wxst = m_debugMsg;
< wxst = wxString("AUTO",wxConvUTF8); //BH
> wxst = "AUTO";
< wxst = wxString("TRIG?",wxConvUTF8); //BH
> wxst = "TRIG?";
Is either some example code or a detailed written description available for the improved DRS4 timing-calibration algorithm described by Daniel Stricker-Shaver at MIC 2012? I think you told me that you had verified the results with your own test set-up, so I figure there must be at least two sets of code in existence to implement this calibration. (I have Daniel's presentation slides.)
I managed to find a ping-pong distribution of cell widths that looks quite similar to that shown in Daniel's slides, using an algorithm similar to the technique one uses to find radial offsets in a tracking chamber (i.e. using residuals weighted by track slope), but I'd rather use the method with which you and Daniel have already found good results. (The attached graph shows in black the histogram of cell widths for essentially the algorithm used in DRS.cpp/DRSBoard::AnalyzeWF, and in blue the histogram of cell widths extracted from the slope-weighted residuals for a periodic reference signal.)
By the way, since Daniel finds a FWHM coincidence-timing resolution around 20-25ps at 5 GSPS (for perfectly identical pulses), should I expect a FWHM resolution (for synthesized, ideal pulses) of around 50-65ps at 2 GSPS?
(I'm posting here instead of writing you both privately because I figure there may be broader interest in Daniel's algorithm.)
We have for some time now been using custom firmware on a custom board to read waveforms out of DRS4 chips. Now we are working on cascaded readout mode, 4 channels @ 2048 samples, WSREG=0x55, in order to allow for longer trigger latency.
Doing a testbench simulation of the FPGA code raised a question for me: Do I need to deassert DENABLE while I shift a new 8-bit value into the write-shift register? What happens if, during the few-hundred nanoseconds it takes to shift 8 bits into the register, the domino wave crosses cell 768, thereby shifting the write-shift register left by one bit? Is this shifting suppressed when A=0b1101? Or does the update of the actual write-shift register occur only once, after the 8th SRCLK cycle? (Maybe one is really shifting bits into a shadow register that is copied all at once into the actual register?)
I notice in simulating your drs4_eval5_app.vhd that if one sets bit 27 ("drs_ctl_dactive") of register 0 (do not deassert DENABLE on trigger), then starts the domino wave (set bit 0 of register 0), then issues a software trigger, then later writes to register 5 (config register, wsreg, etc.), DENABLE is not in fact deasserted during the time when A=0b1100 (conf_setup, conf_strobe) or when A=0b1101 (wsr_setup, wsr_strobe).
But my simulation testbench includes a simplified Verilog model of my interpretation of the DRS4 data sheet, and my simulated DRS4 happened to cause the write-shift register to shift (256 samples before DTAP toggled) during your "wsr_strobe" FSM state, thus corrupting the value that was being shifted into the WSREG via SRIN and SRCLK.
So I'm curious: to be safe, should one deassert DENABLE before updating the write-shift register, or is it safe to update it even while the domino wave is active and looping? It seems easy enough to be safe, since we should only need to write to the WSREG once during the setup phase and then let it loop forever.
Aha -- many thanks. I think what tripped up my test logic is that the "done" state in drs4_eval5_app.vhd that executes post-readout sets DWRITE back to 1 (drs_write_set). If one then writes to FPGA register 5 while the FSM is in the "idle" state, the conf_strobe and wsr_strobe states occur with DWRITE and DENABLE both asserted. This is if one sets the "dactive" bit in the FPGA app code, which is probably not the usual use case. Maybe using the real DRS.cpp avoids this situation. (I was simulating your FPGA code to test my understanding of what our FPGA code should do.)
Anyway, our own use case is fine: as you suggest, we leave DENABLE asserted, but we deassert DWRITE while reading out or while changing DRS4 register values.
you keep DENABLE active all the time to keep the Domino Wave running, but you deassert DWRITE if you change any register via SRCLK. There is no shadow register, just a simple shift register, but with DWRITE being low, the domino circuitry does not touch it.
let me apologize in advance if this has already been covered somewhere and I missed it.
I have a question about a statement made regarding the ADC clock in the evaluation board v4.0 manual. At the bottom or page 23 there is a mention of jitter between the SRCLK signal and the ADC clock causing a baseline variation in the sampled output of up to a few mV. Is there any more information out there about this? I find this confusing for the following reason: If the DRS output has mostly settled after 28ns and the signal that is being sampled is a DC signal, I don't understand why an aperture jitter in the sampling ADC should cause a voltage error in the measured signal. I already know about the possibility of noise spikes every 32 samples if these clocks are not properly aligned, though I don't know the origin of those spikes. are these two things related?
We're developing electronics based on the DRS4 to read out a breast PET scanner and our event rate will be quite high so we're concerned about dead-time. with that in mind, I have a question regarding the mode of simultaneous writing and reading that is described in the DRS4 data sheet. I think the description there is quite clear but I'd like to ask for a few clarifications.
1) Are the channels required to be read out via the channel multiplexer when doing the simultaneous write/read or is it ok to read out all channels in parallel (even the ones still sampling) and just throw away the ones you don't want?
2) If one wanted to use region of interest mode along with the simultaneous write/read, how would that work? Here is what I would think - please tell me if I'm missing some important detail:
-upon trigger, deassert dwrite.
-increment write config register
-start the readout (reading out stop shift register value on SROUT as data comes out)
3) now to add even more complexity - I would actually like to use simultaneous write/read along with region of interest mode and also with pairs of cascaded channels as we need >500ns latency and 2Gsps is too slow for our signals. the combination of cascading and simultaneous write/read is addressed in the data sheet but I still have one question. In normal circumstances when cascading channels, one would read out the value in the write shift register to know which channel was active when the domino wave stopped. I assume that this is not possible when dwrite is enabled as the write shift register is then advanced by the domino wave, so I see three possibilities:
-accept more dead-time and read out the write-shift-register each time (adds ~240ns to deadtime)
-just read out both channels every time and figure out later where is the data you want
-attempt to keep track of the expected state of write-shift-register in firmware.
is there a better option that I have not thought of?
Our setup uses a DRS4 evaluation board (version 2.0).
Although we trigger the board at a rate of ~4kHz (on channel2), readout through USB2 is only happening at a rate of ~125Hz.
After some investigation, we could pin down that it is due to the time it takes to complete the following commands: musb_write() and musb_read() which both take ~150 microsecond to complete. Because they are called multiple times, reading out 1 trigger takes ~8 millisecond which explains the 125Hz we're seeing.
Is ~150 us to complete a musb_read()/musb_write() command expected?
Is there any way we could speed up the readout rate of the DRS4 board so that data acquisition through USB2 is closer to our trigger rate of 4kHz?
Any feedback you might have on this topic would be greatly appreciated.
We want to use the inner DRS4 counter(scaler) within more than the 100ms integration time. We guess that we need to modify the original firmware around this point:
-- Reference clock used for frequency counter
proc_1hzclk: process(I_RESET, I_CLK33)
if (I_RESET = '1') then
drs_1hz_counter(31 downto 0) <= (others => '0');
drs_1hz_clock <= '0';
scaler_reset <= (others => '1');
scaler_ff_reset <= (others => '1');
elsif rising_edge(I_CLK33) then
drs_1hz_counter <= drs_1hz_counter - 1; -- count down
scaler_reset <= (others => '0');
scaler_ff_reset <= (others => '0');
-- toggle refclk if timer expires
if (drs_1hz_counter(drs_1hz_counter'high) = '1') then
drs_1hz_clock <= not drs_1hz_clock;
drs_1hz_counter(31 downto 0) <= X"0016E35F"; -- 1499999, I_CLK33 is actually a 30 MHz clock
scaler_ff_reset <= (others => '1'); -- reset scaler_ff once every 100ms cycle
loop_scaler_reset : for i in 0 to 5 loop
if (scaler_ff(i) = '0') then -- no activity since last cycle?
scaler_reset(i) <= '1'; -- force clear scaler register
if (scaler_ff(0) = '0') then -- no activity since last cycle?
scaler_reset(0) <= '1'; -- force clear scaler register
Could you please tell us how to modify the firmware to increse the time up to 5 seconds for instance?
Thanks in advance, Arseny
For the users using a Macintosh,
after several hours the Evaluation Board is working on my Macintosh (intel).
1) install the development package with xcode, its on the OS X installation DVD
2) install the libusb binary from http://www.ellert.se/twain-sane/
3) modify the makefile for compiling drs_exam (attached) afterwards it's running perfect!
# Makefile for drs_exam executables
# under OS X Macintosh with Bash Shell
CFLAGS = -g -O2 -Wall -Iinclude -DOS_LINUX -DHAVE_LIBUSB
LIBS = -lpthread -lutil -lusb
CPP_OBJ = DRS.o
OBJECTS = musbstd.o mxml.o strlcpy.o
drs_exam: $(OBJECTS) DRS.o drs_exam.o
$(CXX) $(CFLAGS) $(OBJECTS) DRS.o drs_exam.o -o drs_exam $(LIBS)
drs_exam.o: src/drs_exam.cpp include/mxml.h include/DRS.h
$(CXX) $(CFLAGS) -c $<
$(CPP_OBJ): %.o: src/%.cpp include/%.h include/mxml.h include/DRS.h
$(CXX) $(CFLAGS) $(WXFLAGS) -c $<
$(OBJECTS): %.o: src/%.c include/mxml.h include/DRS.h
$(CXX) $(CFLAGS) -c $<
rm -f *.o drscl drsosc