Tue May 26 11:10:27 2020, xggg, Domino wave
|
Hi Stefan,
According to the datasheet DRS_rev09, the write signal is always 16 cells wide. So when the domino wave runs in infinite mode and be stopped by setting DENABLE low , there are always 16 cells capicitors tracking the input signal . It means that the effective sample cells is 1024-16=1008? That's confusing. |
Tue May 26 12:44:16 2020, Stefan Ritt, Domino wave
|
Look at the attached picture. For simplicity, only 4 cells are open and tracking the input signal. Time is flowing from top to bottom. So initially, a train of 4 cells is open. When it's stopped, the train stops not immediately, but kind of "runs against a wall" at the stop cell. So each cell is open for four time ticks effectively, and you can use all 1024 cells.
xggg wrote: |
Hi Stefan,
According to the datasheet DRS_rev09, the write signal is always 16 cells wide. So when the domino wave runs in infinite mode and be stopped by setting DENABLE low , there are always 16 cells capicitors tracking the input signal . It means that the effective sample cells is 1024-16=1008? That's confusing.
|
|
Thu May 21 07:18:48 2020, Keita Mizukoshi, DRS4 Evaluation board control tool 'drscl' with macro file
|
Dear experts,
I would like to use DRS4 evaluation board as DAQ system for small, table-top experiment.
I need waveforms capture as binary file on some trigger based on command line without GUI.
I found `drscl` tool in official software, but it require interactive command. I'd rather use static macro or so on to control DAQ as same behaviour in each time.
I guess, experts are thinking users should develop DAQ code by themselves for their experiment specifically, but my request is very common so someone has already developed these tool.
Best regards,
Keita |
Fri May 22 12:53:33 2020, Stefan Ritt, DRS4 Evaluation board control tool 'drscl' with macro file
|
There is an example program in the distribution under software/drscl/drs_exam.cpp which is a stand-alone program to do what you need. It uses the C library coming with the distribution. It configureres the board, defines a trigger, and then writes a few waveforms into a file. You can use it as a starting point for your development. If you need any other language, you have to develop bindings to the C library.
Stefan
Keita Mizukoshi wrote: |
Dear experts,
I would like to use DRS4 evaluation board as DAQ system for small, table-top experiment.
I need waveforms capture as binary file on some trigger based on command line without GUI.
I found `drscl` tool in official software, but it require interactive command. I'd rather use static macro or so on to control DAQ as same behaviour in each time.
I guess, experts are thinking users should develop DAQ code by themselves for their experiment specifically, but my request is very common so someone has already developed these tool.
Best regards,
Keita
|
|
Mon May 25 03:36:12 2020, Keita Mizukoshi, DRS4 Evaluation board control tool 'drscl' with macro file
|
Thank you very much. That is what I wanted.
Stefan Ritt wrote: |
There is an example program in the distribution under software/drscl/drs_exam.cpp which is a stand-alone program to do what you need. It uses the C library coming with the distribution. It configureres the board, defines a trigger, and then writes a few waveforms into a file. You can use it as a starting point for your development. If you need any other language, you have to develop bindings to the C library.
Stefan
Keita Mizukoshi wrote: |
Dear experts,
I would like to use DRS4 evaluation board as DAQ system for small, table-top experiment.
I need waveforms capture as binary file on some trigger based on command line without GUI.
I found `drscl` tool in official software, but it require interactive command. I'd rather use static macro or so on to control DAQ as same behaviour in each time.
I guess, experts are thinking users should develop DAQ code by themselves for their experiment specifically, but my request is very common so someone has already developed these tool.
Best regards,
Keita
|
|
|
Thu May 21 07:38:05 2020, Keita Mizukoshi, Type check at DOFrame.h in official software
|
Hi,
I've failured to compile official software. The cause is the following line.
DOFrame.h L.111 bool GetRefclk() { return m_refClk > 0; }
m_refClk is pointer to bool. I guess these line is for null-check of the pointer.
Can I replace the following line as
bool GetRefclk() { return m_refClk != nullptr; }
?
The latest compilers may not accept C-style check.
My compiler version is
Apple clang version 11.0.3 (clang-1103.0.32.59)
Target: x86_64-apple-darwin19.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Best regards,
Keita |
Fri May 22 13:24:51 2020, Stefan Ritt, Type check at DOFrame.h in official software
|
The software is a bit outdated, I will soon make a new release.
In meantime, you can replace that like with
bool GetRefclk(int board) { return m_refClk[board]; }
Best,
Stefan
Keita Mizukoshi wrote: |
Hi,
I've failured to compile official software. The cause is the following line.
DOFrame.h L.111 bool GetRefclk() { return m_refClk > 0; }
m_refClk is pointer to bool. I guess these line is for null-check of the pointer.
Can I replace the following line as
bool GetRefclk() { return m_refClk != nullptr; }
?
The latest compilers may not accept C-style check.
My compiler version is
Apple clang version 11.0.3 (clang-1103.0.32.59)
Target: x86_64-apple-darwin19.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Best regards,
Keita
|
|
Mon Mar 23 15:03:28 2020, Ajay Krishnamurthy, USB trigger issue
|
Hello,
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.
Thanks,
Ajay |
Wed Oct 23 17:56:26 2019, John Jendzurski, Computing corrected time from binary data...what is t_0,0?
|
In the equations for computing the corrected time for channels other than channel 1, does anyone know what the term t0,0 refers to? This is the last term in the last equation on page 24 of DRS4 Evaluation Board User’s Manual, Board Revision 5 as of January 2014, Last revised: April 27, 2016.
Screenshot from User's Manual is attached below.
Thank you! |
Fri Oct 25 16:39:07 2019, Stefan Ritt, Computing corrected time from binary data...what is t_0,0?
|
t0,0 refers to the time of cell #0 of channel #0. So basically you keep channel 0 fixed, calculate the difference of each channel's cell #0 in respect to channel 0, and align all channels except channel 0 so that their cell #0 has the same value. There is an inconsistency between the channel numbering. The formula uses 0...3 and the manual says "channel 1" but it means actually the first channel, which uses index "0".
Stefan
John Jendzurski wrote: |
In the equations for computing the corrected time for channels other than channel 1, does anyone know what the term t0,0 refers to? This is the last term in the last equation on page 24 of DRS4 Evaluation Board User’s Manual, Board Revision 5 as of January 2014, Last revised: April 27, 2016.
Screenshot from User's Manual is attached below.
Thank you!
|
|
Mon Oct 14 09:32:33 2019, Danyang, how to acquire the stop position with channel cascading
|
Hi Steffan,
In DSR4 DATASHEET Rev.0.9 Page13, there is a paragraph "If the DRS4 is configured for channel cascading or daisy chaining, it is necessary to know which the current channel is where the sampling has been stopped. This can be
determined by addressing the Write Shift Register withA3-A0 = 1101b and by applying clock pulses to the SRCLK input ...".
My question is the timing details about srclk, srout, A3-A0 in the above control and its timing relation with stop shift register (Figure 15). And can this configuration be used in the full readout mode with output MUXOUT?
Best Regards,
Danyang (sun2222@mail.ustc.edu.cn) |
Mon Oct 14 10:14:46 2019, Stefan Ritt, how to acquire the stop position with channel cascading
|
You first set A3-A0, on the next clock cycle you issue pulses on srclk, and about 10ns after each clock pulse the output shows up at srout. Best is to verity this with an oscilloscope.
The radout of the shift register is independent of the readout mode, so you can use with with MUXOUT as well.
Stefan
Danyang wrote: |
Hi Steffan,
In DSR4 DATASHEET Rev.0.9 Page13, there is a paragraph "If the DRS4 is configured for channel cascading or daisy chaining, it is necessary to know which the current channel is where the sampling has been stopped. This can be
determined by addressing the Write Shift Register withA3-A0 = 1101b and by applying clock pulses to the SRCLK input ...".
My question is the timing details about srclk, srout, A3-A0 in the above control and its timing relation with stop shift register (Figure 15). And can this configuration be used in the full readout mode with output MUXOUT?
Best Regards,
Danyang (sun2222@mail.ustc.edu.cn)
|
|
Mon Oct 14 11:45:06 2019, Danyang, how to acquire the stop position with channel cascading
|
I tried the logic in my designed board. The results are shown in the picture: Srout keeps low when A3-A0 is set to 1101 and srclk is set as you mentioned. And the drs4 chip does not output sine wave in such configuration.
Srout signal only reacts after the rsrload signal is pulled high and A3-A0 is not 1101.
The number of srclk is not enough? Is there any recommended time to configure the command?
Best Regards,
Danyang
Stefan Ritt wrote: |
You first set A3-A0, on the next clock cycle you issue pulses on srclk, and about 10ns after each clock pulse the output shows up at srout. Best is to verity this with an oscilloscope.
The radout of the shift register is independent of the readout mode, so you can use with with MUXOUT as well.
Stefan
Danyang wrote: |
Hi Steffan,
In DSR4 DATASHEET Rev.0.9 Page13, there is a paragraph "If the DRS4 is configured for channel cascading or daisy chaining, it is necessary to know which the current channel is where the sampling has been stopped. This can be
determined by addressing the Write Shift Register withA3-A0 = 1101b and by applying clock pulses to the SRCLK input ...".
My question is the timing details about srclk, srout, A3-A0 in the above control and its timing relation with stop shift register (Figure 15). And can this configuration be used in the full readout mode with output MUXOUT?
Best Regards,
Danyang (sun2222@mail.ustc.edu.cn)
|
|
|
Mon Oct 14 12:56:13 2019, Stefan Ritt, how to acquire the stop position with channel cascading
|
Note that you have to read out the Write Shift Register only if you do channel cascading, e.g. configuring the chip with 4x2048 bins by setting the Write Shift Register to 01010101b. Then the Write Shift Register tells you in which 1024-bin segment the Domino Wave has been stopped. If you use the normal 8x1024 bin mode, you don't have to read out the Write Shift Register since it continas only 1's.
Stefan
Danyang wrote: |
I tried the logic in my designed board. The results are shown in the picture: Srout keeps low when A3-A0 is set to 1101 and srclk is set as you mentioned. And the drs4 chip does not output sine wave in such configuration.
Srout signal only reacts after the rsrload signal is pulled high and A3-A0 is not 1101.
The number of srclk is not enough? Is there any recommended time to configure the command?
Best Regards,
Danyang
Stefan Ritt wrote: |
You first set A3-A0, on the next clock cycle you issue pulses on srclk, and about 10ns after each clock pulse the output shows up at srout. Best is to verity this with an oscilloscope.
The radout of the shift register is independent of the readout mode, so you can use with with MUXOUT as well.
Stefan
Danyang wrote: |
Hi Steffan,
In DSR4 DATASHEET Rev.0.9 Page13, there is a paragraph "If the DRS4 is configured for channel cascading or daisy chaining, it is necessary to know which the current channel is where the sampling has been stopped. This can be
determined by addressing the Write Shift Register withA3-A0 = 1101b and by applying clock pulses to the SRCLK input ...".
My question is the timing details about srclk, srout, A3-A0 in the above control and its timing relation with stop shift register (Figure 15). And can this configuration be used in the full readout mode with output MUXOUT?
Best Regards,
Danyang (sun2222@mail.ustc.edu.cn)
|
|
|
|
Mon Oct 14 13:44:26 2019, Danyang, how to acquire the stop position with channel cascading
|
Yes, firstly I configured the chip with 4x2048 bins by setting the Write Shift Register to 01010101b, A3-A0 keeps 1101----> secondly I enabled the domino wave, wait some time for stable, A3-A0 keeps 1111 ---->thirdly stops the domino wave when the trigger comes, A3-A0 keeps 1101 (or 1010, 0000)----> forthly send the clock pulse to the srclk pin, A3-A0 keeps 1101, srout pin keeps low----> fifthly enable rsrload, A3-A0 (0000-1000), srout pin reacts nomally. I think the cascading is worked when I checked the waveform on the oscilloscope. Is there any step I missed?
Best Regards,
Danyang
Stefan Ritt wrote: |
Note that you have to read out the Write Shift Register only if you do channel cascading, e.g. configuring the chip with 4x2048 bins by setting the Write Shift Register to 01010101b. Then the Write Shift Register tells you in which 1024-bin segment the Domino Wave has been stopped. If you use the normal 8x1024 bin mode, you don't have to read out the Write Shift Register since it continas only 1's.
Stefan
Danyang wrote: |
I tried the logic in my designed board. The results are shown in the picture: Srout keeps low when A3-A0 is set to 1101 and srclk is set as you mentioned. And the drs4 chip does not output sine wave in such configuration.
Srout signal only reacts after the rsrload signal is pulled high and A3-A0 is not 1101.
The number of srclk is not enough? Is there any recommended time to configure the command?
Best Regards,
Danyang
Stefan Ritt wrote: |
You first set A3-A0, on the next clock cycle you issue pulses on srclk, and about 10ns after each clock pulse the output shows up at srout. Best is to verity this with an oscilloscope.
The radout of the shift register is independent of the readout mode, so you can use with with MUXOUT as well.
Stefan
Danyang wrote: |
Hi Steffan,
In DSR4 DATASHEET Rev.0.9 Page13, there is a paragraph "If the DRS4 is configured for channel cascading or daisy chaining, it is necessary to know which the current channel is where the sampling has been stopped. This can be
determined by addressing the Write Shift Register withA3-A0 = 1101b and by applying clock pulses to the SRCLK input ...".
My question is the timing details about srclk, srout, A3-A0 in the above control and its timing relation with stop shift register (Figure 15). And can this configuration be used in the full readout mode with output MUXOUT?
Best Regards,
Danyang (sun2222@mail.ustc.edu.cn)
|
|
|
|
|
Mon Oct 14 15:27:09 2019, Stefan Ritt, how to acquire the stop position with channel cascading
|
If you configure the Write Shift Register with 01010101b, then all you have to do after a trigger is to set A3-A0 to 1101. The WSROUT pin shows you then either ther state 01010101b or 10101010b, you the pin should be 1 or 0, and that's all you need. The Write Shift Register is NOT routed to the SROUT pin, you only see it at the WSROUT pin.
Stefan
Danyang wrote: |
Yes, firstly I configured the chip with 4x2048 bins by setting the Write Shift Register to 01010101b, A3-A0 keeps 1101----> secondly I enabled the domino wave, wait some time for stable, A3-A0 keeps 1111 ---->thirdly stops the domino wave when the trigger comes, A3-A0 keeps 1101 (or 1010, 0000)----> forthly send the clock pulse to the srclk pin, A3-A0 keeps 1101, srout pin keeps low----> fifthly enable rsrload, A3-A0 (0000-1000), srout pin reacts nomally. I think the cascading is worked when I checked the waveform on the oscilloscope. Is there any step I missed?
Best Regards,
Danyang
Stefan Ritt wrote: |
Note that you have to read out the Write Shift Register only if you do channel cascading, e.g. configuring the chip with 4x2048 bins by setting the Write Shift Register to 01010101b. Then the Write Shift Register tells you in which 1024-bin segment the Domino Wave has been stopped. If you use the normal 8x1024 bin mode, you don't have to read out the Write Shift Register since it continas only 1's.
Stefan
Danyang wrote: |
I tried the logic in my designed board. The results are shown in the picture: Srout keeps low when A3-A0 is set to 1101 and srclk is set as you mentioned. And the drs4 chip does not output sine wave in such configuration.
Srout signal only reacts after the rsrload signal is pulled high and A3-A0 is not 1101.
The number of srclk is not enough? Is there any recommended time to configure the command?
Best Regards,
Danyang
Stefan Ritt wrote: |
You first set A3-A0, on the next clock cycle you issue pulses on srclk, and about 10ns after each clock pulse the output shows up at srout. Best is to verity this with an oscilloscope.
The radout of the shift register is independent of the readout mode, so you can use with with MUXOUT as well.
Stefan
Danyang wrote: |
Hi Steffan,
In DSR4 DATASHEET Rev.0.9 Page13, there is a paragraph "If the DRS4 is configured for channel cascading or daisy chaining, it is necessary to know which the current channel is where the sampling has been stopped. This can be
determined by addressing the Write Shift Register withA3-A0 = 1101b and by applying clock pulses to the SRCLK input ...".
My question is the timing details about srclk, srout, A3-A0 in the above control and its timing relation with stop shift register (Figure 15). And can this configuration be used in the full readout mode with output MUXOUT?
Best Regards,
Danyang (sun2222@mail.ustc.edu.cn)
|
|
|
|
|
|
Tue Oct 15 08:14:17 2019, Danyang, how to acquire the stop position with channel cascading
|
Thanks a lot. The problem is solved when A3-A0 is set 1101 and srclk keeps low.
Best Regards,
Danyang
Stefan Ritt wrote: |
If you configure the Write Shift Register with 01010101b, then all you have to do after a trigger is to set A3-A0 to 1101. The WSROUT pin shows you then either ther state 01010101b or 10101010b, you the pin should be 1 or 0, and that's all you need. The Write Shift Register is NOT routed to the SROUT pin, you only see it at the WSROUT pin.
Stefan
Danyang wrote: |
Yes, firstly I configured the chip with 4x2048 bins by setting the Write Shift Register to 01010101b, A3-A0 keeps 1101----> secondly I enabled the domino wave, wait some time for stable, A3-A0 keeps 1111 ---->thirdly stops the domino wave when the trigger comes, A3-A0 keeps 1101 (or 1010, 0000)----> forthly send the clock pulse to the srclk pin, A3-A0 keeps 1101, srout pin keeps low----> fifthly enable rsrload, A3-A0 (0000-1000), srout pin reacts nomally. I think the cascading is worked when I checked the waveform on the oscilloscope. Is there any step I missed?
Best Regards,
Danyang
Stefan Ritt wrote: |
Note that you have to read out the Write Shift Register only if you do channel cascading, e.g. configuring the chip with 4x2048 bins by setting the Write Shift Register to 01010101b. Then the Write Shift Register tells you in which 1024-bin segment the Domino Wave has been stopped. If you use the normal 8x1024 bin mode, you don't have to read out the Write Shift Register since it continas only 1's.
Stefan
Danyang wrote: |
I tried the logic in my designed board. The results are shown in the picture: Srout keeps low when A3-A0 is set to 1101 and srclk is set as you mentioned. And the drs4 chip does not output sine wave in such configuration.
Srout signal only reacts after the rsrload signal is pulled high and A3-A0 is not 1101.
The number of srclk is not enough? Is there any recommended time to configure the command?
Best Regards,
Danyang
Stefan Ritt wrote: |
You first set A3-A0, on the next clock cycle you issue pulses on srclk, and about 10ns after each clock pulse the output shows up at srout. Best is to verity this with an oscilloscope.
The radout of the shift register is independent of the readout mode, so you can use with with MUXOUT as well.
Stefan
Danyang wrote: |
Hi Steffan,
In DSR4 DATASHEET Rev.0.9 Page13, there is a paragraph "If the DRS4 is configured for channel cascading or daisy chaining, it is necessary to know which the current channel is where the sampling has been stopped. This can be
determined by addressing the Write Shift Register withA3-A0 = 1101b and by applying clock pulses to the SRCLK input ...".
My question is the timing details about srclk, srout, A3-A0 in the above control and its timing relation with stop shift register (Figure 15). And can this configuration be used in the full readout mode with output MUXOUT?
Best Regards,
Danyang (sun2222@mail.ustc.edu.cn)
|
|
|
|
|
|
|
Fri Sep 13 15:27:41 2019, Arseny Rybnikov, Scaler / How to modify the firmware to change the scaler integration time
|
Hello,
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)
begin
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
end if;
end loop;
if (scaler_ff(0) = '0') then -- no activity since last cycle?
scaler_reset(0) <= '1'; -- force clear scaler register
end if;
end if;
end if;
end process;
Could you please tell us how to modify the firmware to increse the time up to 5 seconds for instance?
Thanks in advance, Arseny |
Tue Aug 27 08:33:22 2019, chinmay basu, DRS4
|
Is DRS4 suitable for use with Silicon surface barrier detectors? |
Tue Aug 27 09:14:03 2019, Stefan Ritt, DRS4
|
Is a 5 GSPS oscilloscope suitable for use with Silicon surface barier detectors?
chinmay basu wrote: |
Is DRS4 suitable for use with Silicon surface barrier detectors?
|
|
Mon Aug 19 23:01:22 2019, Bill Ashmanskas, should one deassert DENABLE while writing the write-shift register?
|
Hi Stefan,
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.
Many thanks,
Bill
|
Tue Aug 20 10:44:45 2019, Stefan Ritt, should one deassert DENABLE while writing the write-shift register?
|
Hi Bill,
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.
Best,
Stefan
Bill Ashmanskas wrote: |
Hi Stefan,
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.
Many thanks,
Bill
|
|
Tue Aug 20 16:05:21 2019, Bill Ashmanskas, should one deassert DENABLE while writing the write-shift register?
|
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.
Thanks again,
Bill
Stefan Ritt wrote: |
Hi Bill,
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.
Best,
Stefan
Bill Ashmanskas wrote: |
Hi Stefan,
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.
Many thanks,
Bill
|
|
|
Thu Jul 18 01:03:44 2019, Ismael Garcia, Trace Impedance
|
Hi Steffan,
I'm an engineer at UCLA developing a board with the DRS4 chip. Our team has a question on what might be the required trace impedence for the analog inputs. Can that information be provided?
Best Regards,
Ismael Garcia
|
Thu Jul 18 11:37:56 2019, Stefan Ritt, Trace Impedance
|
The requiremnet is the same as for any high speed analog board, there is othing special with the DRS4. If you want to terminate your line with 50 Ohms and you want a matched impedance layout, you route all lines with 50 Ohms impedance. Truth is however that nothing is perfect. The SMA connector is not exactly 50 Ohm, the PCB gets a 10-20% variation depending on the manufacturer. So even if you try hard, you will never have a 50 Ohm matched impedance. On the evaluation board we made some compromises as you have seen, but for us the board works satisfactory even with this compromises, and you can test it yourself with real hardware (namely the evaluation board). If you can do a better job, try it. But usually these compromises have only little influence on the signal quality.
Stefan
Ismael Garcia wrote: |
Hi Steffan,
I'm an engineer at UCLA developing a board with the DRS4 chip. Our team has a question on what might be the required trace impedence for the analog inputs. Can that information be provided?
Best Regards,
Ismael Garcia
|
|
Fri Jul 19 01:37:09 2019, Ismael Garcia, Trace Impedance
|
When you're refering to laying a 50 Ohm trace, you're referring to the SMA input and not the interface between the output of the Op-AMP(THS4508) buffer
and the inputs of the DRS4(IN0-IN8). Is there a recommended diffential impedance for IN0-IN8?
Ismael
Stefan Ritt wrote: |
The requiremnet is the same as for any high speed analog board, there is othing special with the DRS4. If you want to terminate your line with 50 Ohms and you want a matched impedance layout, you route all lines with 50 Ohms impedance. Truth is however that nothing is perfect. The SMA connector is not exactly 50 Ohm, the PCB gets a 10-20% variation depending on the manufacturer. So even if you try hard, you will never have a 50 Ohm matched impedance. On the evaluation board we made some compromises as you have seen, but for us the board works satisfactory even with this compromises, and you can test it yourself with real hardware (namely the evaluation board). If you can do a better job, try it. But usually these compromises have only little influence on the signal quality.
Stefan
Ismael Garcia wrote: |
Hi Steffan,
I'm an engineer at UCLA developing a board with the DRS4 chip. Our team has a question on what might be the required trace impedence for the analog inputs. Can that information be provided?
Best Regards,
Ismael Garcia
|
|
|
Sat Jul 20 12:28:14 2019, Stefan Ritt, Trace Impedance
|
The DRS4 input is high impedance. So if you like you can terminate it with 100 Ohm differentially and route it with 100 Ohm. But if you keep the lines short, the reflection is negligible. That’s what we made on the evaluation board.
Ismael Garcia wrote: |
When you're refering to laying a 50 Ohm trace, you're referring to the SMA input and not the interface between the output of the Op-AMP(THS4508) buffer
and the inputs of the DRS4(IN0-IN8). Is there a recommended diffential impedance for IN0-IN8?
Ismael
Stefan Ritt wrote: |
The requiremnet is the same as for any high speed analog board, there is othing special with the DRS4. If you want to terminate your line with 50 Ohms and you want a matched impedance layout, you route all lines with 50 Ohms impedance. Truth is however that nothing is perfect. The SMA connector is not exactly 50 Ohm, the PCB gets a 10-20% variation depending on the manufacturer. So even if you try hard, you will never have a 50 Ohm matched impedance. On the evaluation board we made some compromises as you have seen, but for us the board works satisfactory even with this compromises, and you can test it yourself with real hardware (namely the evaluation board). If you can do a better job, try it. But usually these compromises have only little influence on the signal quality.
Stefan
Ismael Garcia wrote: |
Hi Steffan,
I'm an engineer at UCLA developing a board with the DRS4 chip. Our team has a question on what might be the required trace impedence for the analog inputs. Can that information be provided?
Best Regards,
Ismael Garcia
|
|
|
|
Sat Jul 13 01:00:15 2019, Brendan Posehn, Evaluation Board Test Functionality
|
Hello,
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,
Brendan |
Mon Jul 15 17:26:50 2019, Stefan Ritt, Evaluation Board Test Functionality
|
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?
Stefan
Brendan Posehn wrote: |
Hello,
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,
Brendan
|
|
Mon Jul 15 19:34:25 2019, Brendan Posehn, Evaluation Board Test Functionality
|
Hello Stefan,
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,
Brendan
Stefan Ritt wrote: |
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?
Stefan
Brendan Posehn wrote: |
Hello,
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,
Brendan
|
|
|
Tue Jun 25 23:04:29 2019, Si Xie, drs_exam is always reading out a sin wave
|
We are using the drs_exam.cpp to read out waveforms, but it seems to be outputting only sin waves on all channels - as if it was reading out the simulated waveform from the oscilloscope program if we run it without the board plugged in. Does anyone know what is causing this?
We are taking data with a pulser plugged into channel 1, which produces a single pulse with width of 8ns, and nothing plugged into channel 2.
Our board is as follows:
Found DRS4 evaluation board, serial #2567, firmware revision 21305
Board type: 9
The output is something like the following:
Event #0 ----------------------
t1[ns] u1[mV] t2[ns] u2[mV]
0.000 -452.7 0.026 -469.3
0.289 -460.8 0.293 -469.8
0.413 -477.3 0.400 -481.5
0.642 -485.3 0.650 -482.4
0.806 -486.9 0.821 -477.8
1.086 -476.8 1.085 -457.2
1.183 -467.3 1.162 -446.4
1.450 -435.6 1.459 -405.1
1.619 -410.1 1.630 -373.3
1.843 -366.2 1.851 -323.9
1.945 -342.9 1.948 -298.9
2.221 -275.7 2.210 -229.3
2.359 -237.6 2.357 -187.6
2.602 -165.6 2.609 -111.2
2.687 -141.1 2.697 -84.3
2.976 -50.5 2.987 5.5
3.164 8.4 3.144 53.3
3.377 73.9 3.384 124.2
3.503 111.4 3.506 158.0
3.753 182.0 3.769 226.9
3.924 227.5 3.929 265.8
|
Wed Jun 26 13:08:42 2019, Stefan Ritt, drs_exam is always reading out a sin wave
|
Sure, that’s correct. The example program turns on the internal sine wave generator in case people don’t have a real signal. That’s why it’s called „example“. Find the code which turns on the generator and change it. You will also have to change the trigger settings depending on your actual signal.
Stefan
Si Xie wrote: |
We are using the drs_exam.cpp to read out waveforms, but it seems to be outputting only sin waves on all channels - as if it was reading out the simulated waveform from the oscilloscope program if we run it without the board plugged in. Does anyone know what is causing this?
We are taking data with a pulser plugged into channel 1, which produces a single pulse with width of 8ns, and nothing plugged into channel 2.
Our board is as follows:
Found DRS4 evaluation board, serial #2567, firmware revision 21305
Board type: 9
The output is something like the following:
Event #0 ----------------------
t1[ns] u1[mV] t2[ns] u2[mV]
0.000 -452.7 0.026 -469.3
0.289 -460.8 0.293 -469.8
0.413 -477.3 0.400 -481.5
0.642 -485.3 0.650 -482.4
0.806 -486.9 0.821 -477.8
1.086 -476.8 1.085 -457.2
1.183 -467.3 1.162 -446.4
1.450 -435.6 1.459 -405.1
1.619 -410.1 1.630 -373.3
1.843 -366.2 1.851 -323.9
1.945 -342.9 1.948 -298.9
2.221 -275.7 2.210 -229.3
2.359 -237.6 2.357 -187.6
2.602 -165.6 2.609 -111.2
2.687 -141.1 2.697 -84.3
2.976 -50.5 2.987 5.5
3.164 8.4 3.144 53.3
3.377 73.9 3.384 124.2
3.503 111.4 3.506 158.0
3.753 182.0 3.769 226.9
3.924 227.5 3.929 265.8
|
|
Wed Jun 26 15:10:09 2019, Si Xie, drs_exam is always reading out a sin wave
|
I see. Where is the code that we can use to turn off the generator? I thought the example is taking data with CH1 as the trigger.
For our board, which is BoardType == 9, it is running these lines:
b->EnableTrigger(1, 0); // enable hardware trigger
b->SetTriggerSource(1<<0); // set CH1 as source
Is that not using the hardware trigger with CH1 as the source?
Stefan Ritt wrote: |
Sure, that’s correct. The example program turns on the internal sine wave generator in case people don’t have a real signal. That’s why it’s called „example“. Find the code which turns on the generator and change it. You will also have to change the trigger settings depending on your actual signal.
Stefan
Si Xie wrote: |
We are using the drs_exam.cpp to read out waveforms, but it seems to be outputting only sin waves on all channels - as if it was reading out the simulated waveform from the oscilloscope program if we run it without the board plugged in. Does anyone know what is causing this?
We are taking data with a pulser plugged into channel 1, which produces a single pulse with width of 8ns, and nothing plugged into channel 2.
Our board is as follows:
Found DRS4 evaluation board, serial #2567, firmware revision 21305
Board type: 9
The output is something like the following:
Event #0 ----------------------
t1[ns] u1[mV] t2[ns] u2[mV]
0.000 -452.7 0.026 -469.3
0.289 -460.8 0.293 -469.8
0.413 -477.3 0.400 -481.5
0.642 -485.3 0.650 -482.4
0.806 -486.9 0.821 -477.8
1.086 -476.8 1.085 -457.2
1.183 -467.3 1.162 -446.4
1.450 -435.6 1.459 -405.1
1.619 -410.1 1.630 -373.3
1.843 -366.2 1.851 -323.9
1.945 -342.9 1.948 -298.9
2.221 -275.7 2.210 -229.3
2.359 -237.6 2.357 -187.6
2.602 -165.6 2.609 -111.2
2.687 -141.1 2.697 -84.3
2.976 -50.5 2.987 5.5
3.164 8.4 3.144 53.3
3.377 73.9 3.384 124.2
3.503 111.4 3.506 158.0
3.753 182.0 3.769 226.9
3.924 227.5 3.929 265.8
|
|
|
Mon Jul 8 14:29:12 2019, Stefan Ritt, drs_exam is always reading out a sin wave
|
Actually in the original drs_exam.cpp the sine wave oscillator is turned off with this command
/* use following line to turn on the internal 100 MHz clock connected to all channels */
//b->EnableTcal(1);
If you remove the "//" then the generator gets enabled. Probably you did this by accident. With this line commented out, you see the proper input like this:
Event #0 ----------------------
t1[ns] u1[mV] t2[ns] u2[mV]
0.000 1.9 0.000 -2.4
0.195 0.5 0.195 0.3
0.391 0.1 0.391 -1.4
0.586 -0.7 0.586 -0.4
0.781 -1.1 0.781 -2.4
0.977 -0.6 0.977 0.0
1.172 -1.5 1.172 -2.8
1.367 -0.4 1.367 -0.6
1.562 -1.2 1.562 -3.8
1.758 -1.5 1.758 -1.7
1.953 -1.0 1.953 -3.3
2.148 -0.7 2.148 -1.8
2.344 -1.6 2.344 -4.2
2.539 0.5 2.539 -1.5
2.734 0.2 2.734 -3.6
...
167.969 -3.4 167.969 -5.2
168.164 -3.7 168.164 -3.6
168.359 0.0 168.359 -2.0
168.555 1.9 168.555 -0.2
168.750 2.8 168.750 -2.8
168.945 5.4 168.945 -1.4
169.141 18.0 169.141 1.2
169.336 26.6 169.336 2.7
169.531 46.2 169.531 0.4
169.727 56.2 169.727 1.6
169.922 93.3 169.922 0.1
170.117 115.6 170.117 0.0
170.312 174.4 170.312 -1.5
170.508 206.9 170.508 -0.8
170.703 282.2 170.703 -2.4
170.898 328.4 170.898 -1.2
171.094 419.6 171.094 -3.2
171.289 465.8 171.289 -2.5
171.484 500.0 171.484 -2.0
171.680 500.0 171.680 -0.6
171.875 500.0 171.875 -4.0
172.070 500.0 172.070 -1.1
172.266 500.0 172.266 -3.7
172.461 500.0 172.461 -2.1
172.656 500.0 172.656 -5.0
172.852 500.0 172.852 -3.3
173.047 500.0 173.047 -4.8
173.242 500.0 173.242 -4.1
173.438 500.0 173.438 -5.1
173.633 500.0 173.633 -3.3
173.828 500.0 173.828 -6.4
174.023 500.0 174.023 -3.9
174.219 500.0 174.219 -5.5
174.414 500.0 174.414 -3.2
174.609 500.0 174.609 -3.6
174.805 500.0 174.805 -2.6
175.000 500.0 175.000 -5.2
175.195 500.0 175.195 -2.7
175.391 434.3 175.391 -3.9
175.586 391.7 175.586 -2.4
175.781 312.2 175.781 -4.1
175.977 275.7 175.977 -1.8
176.172 202.4 176.172 -3.8
176.367 167.6 176.367 -1.4
176.562 117.4 176.562 -2.9
176.758 96.1 176.758 -2.3
176.953 62.8 176.953 -3.3
177.148 49.1 177.148 -1.8
177.344 35.9 177.344 -4.3
177.539 33.4 177.539 -2.6
177.734 30.4 177.734 -4.2
...
Si Xie wrote: |
I see. Where is the code that we can use to turn off the generator? I thought the example is taking data with CH1 as the trigger.
For our board, which is BoardType == 9, it is running these lines:
b->EnableTrigger(1, 0); // enable hardware trigger
b->SetTriggerSource(1<<0); // set CH1 as source
Is that not using the hardware trigger with CH1 as the source?
Stefan Ritt wrote: |
Sure, that’s correct. The example program turns on the internal sine wave generator in case people don’t have a real signal. That’s why it’s called „example“. Find the code which turns on the generator and change it. You will also have to change the trigger settings depending on your actual signal.
Stefan
Si Xie wrote: |
We are using the drs_exam.cpp to read out waveforms, but it seems to be outputting only sin waves on all channels - as if it was reading out the simulated waveform from the oscilloscope program if we run it without the board plugged in. Does anyone know what is causing this?
We are taking data with a pulser plugged into channel 1, which produces a single pulse with width of 8ns, and nothing plugged into channel 2.
Our board is as follows:
Found DRS4 evaluation board, serial #2567, firmware revision 21305
Board type: 9
The output is something like the following:
Event #0 ----------------------
t1[ns] u1[mV] t2[ns] u2[mV]
0.000 -452.7 0.026 -469.3
0.289 -460.8 0.293 -469.8
0.413 -477.3 0.400 -481.5
0.642 -485.3 0.650 -482.4
0.806 -486.9 0.821 -477.8
1.086 -476.8 1.085 -457.2
1.183 -467.3 1.162 -446.4
1.450 -435.6 1.459 -405.1
1.619 -410.1 1.630 -373.3
1.843 -366.2 1.851 -323.9
1.945 -342.9 1.948 -298.9
2.221 -275.7 2.210 -229.3
2.359 -237.6 2.357 -187.6
2.602 -165.6 2.609 -111.2
2.687 -141.1 2.697 -84.3
2.976 -50.5 2.987 5.5
3.164 8.4 3.144 53.3
3.377 73.9 3.384 124.2
3.503 111.4 3.506 158.0
3.753 182.0 3.769 226.9
3.924 227.5 3.929 265.8
|
|
|
|
Wed Mar 7 22:49:38 2018, Rodrigo Trindade de Menezes, Running drs_example.cpp
|
Hello,
We have been using the DRS4 evaluation board (S/N 2636) that works with the scope application. However we are trying to run the DRS4 evaluation board remotely by modifying the drs_exam.cpp to acquire and store data continuously.
We compiled the DRS_example.cpp without the wxWidgets but when we try to run the program, it appears to trigger on nonsense. The program appears to not be sensitive to the trigger threshold (although for very large trigger threshold it gets stuck in a waiting mode). Is there a way to ensure that the "normal" trigger mode is set? We are worried that the auto mode is running. Otherwise, not sure why the program is triggering on nonsense. By the way, it does not work with the wxWidgets compiled either so we are worried that there is an additional flag that needs to be set. The routine does not appear to conduct a calibration -- is this not necessary?
Another issue that we are having is with the data set stored on the .txt file looks incorrect. The time channel stops at 200 (but we think it should go up to 1024). In addition, the voltage channel appears to hover around small values near zero (as if triggering on noise). The output file appears this way even when we change the threshold to much higher values. It suggests that the trigger threshold is not actually being set? There are events where the output voltage appears to oscillate through huge negative and positive values too. So not sure what's going on.
Thanks!
Rodrigo |
Thu Mar 8 22:54:20 2018, Rodrigo Trindade de Menezes, Running drs_example.cpp
|
We found a way to solve the previous problem, but right now when we try to set the input range only -0.5 to 0.5 is working. When we set the function "SetInputRange(0.5)" for 0 to 1V the output is all zeros and with "SetInputRange(0.45)" we just get all the outputs -49.9mV. What does that means? How to fix?
odrigo Trindade de Menezes wrote: |
Hello,
We have been using the DRS4 evaluation board (S/N 2636) that works with the scope application. However we are trying to run the DRS4 evaluation board remotely by modifying the drs_exam.cpp to acquire and store data continuously.
We compiled the DRS_example.cpp without the wxWidgets but when we try to run the program, it appears to trigger on nonsense. The program appears to not be sensitive to the trigger threshold (although for very large trigger threshold it gets stuck in a waiting mode). Is there a way to ensure that the "normal" trigger mode is set? We are worried that the auto mode is running. Otherwise, not sure why the program is triggering on nonsense. By the way, it does not work with the wxWidgets compiled either so we are worried that there is an additional flag that needs to be set. The routine does not appear to conduct a calibration -- is this not necessary?
Another issue that we are having is with the data set stored on the .txt file looks incorrect. The time channel stops at 200 (but we think it should go up to 1024). In addition, the voltage channel appears to hover around small values near zero (as if triggering on noise). The output file appears this way even when we change the threshold to much higher values. It suggests that the trigger threshold is not actually being set? There are events where the output voltage appears to oscillate through huge negative and positive values too. So not sure what's going on.
Thanks!
Rodrigo
|
|
Fri May 4 12:11:57 2018, Stefan Ritt, Running drs_example.cpp
|
And here is the second part of your answer: When you change the input range, you have to redo the voltage calibration. Best is if you do that in the DRSOsc program, then you see that it's working. Then start your custom program and use the same range.
Stefan
Rodrigo Trindade de Menezes wrote: |
We found a way to solve the previous problem, but right now when we try to set the input range only -0.5 to 0.5 is working. When we set the function "SetInputRange(0.5)" for 0 to 1V the output is all zeros and with "SetInputRange(0.45)" we just get all the outputs -49.9mV. What does that means? How to fix?
odrigo Trindade de Menezes wrote: |
Hello,
We have been using the DRS4 evaluation board (S/N 2636) that works with the scope application. However we are trying to run the DRS4 evaluation board remotely by modifying the drs_exam.cpp to acquire and store data continuously.
We compiled the DRS_example.cpp without the wxWidgets but when we try to run the program, it appears to trigger on nonsense. The program appears to not be sensitive to the trigger threshold (although for very large trigger threshold it gets stuck in a waiting mode). Is there a way to ensure that the "normal" trigger mode is set? We are worried that the auto mode is running. Otherwise, not sure why the program is triggering on nonsense. By the way, it does not work with the wxWidgets compiled either so we are worried that there is an additional flag that needs to be set. The routine does not appear to conduct a calibration -- is this not necessary?
Another issue that we are having is with the data set stored on the .txt file looks incorrect. The time channel stops at 200 (but we think it should go up to 1024). In addition, the voltage channel appears to hover around small values near zero (as if triggering on noise). The output file appears this way even when we change the threshold to much higher values. It suggests that the trigger threshold is not actually being set? There are events where the output voltage appears to oscillate through huge negative and positive values too. So not sure what's going on.
Thanks!
Rodrigo
|
|
|
Wed Jun 26 15:17:51 2019, Si Xie, Running drs_example.cpp
|
Hi Rodrigo, I'm wondering how you solved your original triggering problem. We are also having trouble with collecting data continously using the example. Thanks.
Rodrigo Trindade de Menezes wrote: |
We found a way to solve the previous problem, but right now when we try to set the input range only -0.5 to 0.5 is working. When we set the function "SetInputRange(0.5)" for 0 to 1V the output is all zeros and with "SetInputRange(0.45)" we just get all the outputs -49.9mV. What does that means? How to fix?
odrigo Trindade de Menezes wrote: |
Hello,
We have been using the DRS4 evaluation board (S/N 2636) that works with the scope application. However we are trying to run the DRS4 evaluation board remotely by modifying the drs_exam.cpp to acquire and store data continuously.
We compiled the DRS_example.cpp without the wxWidgets but when we try to run the program, it appears to trigger on nonsense. The program appears to not be sensitive to the trigger threshold (although for very large trigger threshold it gets stuck in a waiting mode). Is there a way to ensure that the "normal" trigger mode is set? We are worried that the auto mode is running. Otherwise, not sure why the program is triggering on nonsense. By the way, it does not work with the wxWidgets compiled either so we are worried that there is an additional flag that needs to be set. The routine does not appear to conduct a calibration -- is this not necessary?
Another issue that we are having is with the data set stored on the .txt file looks incorrect. The time channel stops at 200 (but we think it should go up to 1024). In addition, the voltage channel appears to hover around small values near zero (as if triggering on noise). The output file appears this way even when we change the threshold to much higher values. It suggests that the trigger threshold is not actually being set? There are events where the output voltage appears to oscillate through huge negative and positive values too. So not sure what's going on.
Thanks!
Rodrigo
|
|
|
Mon Mar 19 15:12:02 2018, Stefan Ritt, Running drs_example.cpp
|
The time channel is already calibrated in ns. So for 5 GSPS, the time scale goes from zero to 200. Concerning your other issues I will come back to you later.
Stefan
Rodrigo Trindade de Menezes wrote: |
Another issue that we are having is with the data set stored on the .txt file looks incorrect. The time channel stops at 200 (but we think it should go up to 1024). In addition, the voltage channel appears to hover around small values near zero (as if triggering on noise). The output file appears this way even when we change the threshold to much higher values. It suggests that the trigger threshold is not actually being set? There are events where the output voltage appears to oscillate through huge negative and positive values too. So not sure what's going on.
|
|
Thu Jun 20 01:36:48 2019, Andrew Peck, Evaluation firmware wait_vdd state
|
Dear Stefan,
I am working with others at UCLA on a custom made board built around the DRS4. We are in the process of writing firmware so I am adapting the readout state machine from the evaluation board firmware.
I see in the state machine of the eval board firmware that after a trigger is received, the FPGA goes into the start readout state and then into "wait_vdd", where the FPGA waits "~120 us for vdd to stabilize" before reading out the ADC.
Our application is sensitive to deadtime and this wait_vdd state adds very significantly. I am trying to find anything explaining the necessity of wait_vdd in the documentation / elog and have only found so far your old forum posting, https://elog.psi.ch/elogs/DRS4+Forum/12
Does this forum posting explain wait_vdd or is there a another purpose that I have missed?
If this post is relevant to wait_vdd, does the advice of large capacitance and an LDO with fast transient response still apply or are there any new recommendations?
Thank you,
Andrew Peck |
Fri Jun 21 12:54:47 2019, Stefan Ritt, Evaluation firmware wait_vdd state
|
Dear Andrew,
the posting you mention is still accurate. Any power supply will drop when you start the Domino wave, no matter how big your capacitor is. Unfortunately the output signal of the DRS4 scales with VDD. So if your VDD drops by 40 mV and you get a trigger and you immediately start the readout, the output baseline will also be shifted by about 40 mV. If you are sensitive to dead time, you can remove the wait_vdd state completely, but then you have to deal with varying baseline shifts. If you have narrow signals sitting on a broad baseline, you can correct for this by measuring the baseline outside your signal, then subtracting it before integrating your pulse. If you have lots of pile-up in your signals, it might sometimes be hard to evaluate the baseline on an event-by-event basis.
Stefan
Andrew Peck wrote: |
Dear Stefan,
I am working with others at UCLA on a custom made board built around the DRS4. We are in the process of writing firmware so I am adapting the readout state machine from the evaluation board firmware.
I see in the state machine of the eval board firmware that after a trigger is received, the FPGA goes into the start readout state and then into "wait_vdd", where the FPGA waits "~120 us for vdd to stabilize" before reading out the ADC.
Our application is sensitive to deadtime and this wait_vdd state adds very significantly. I am trying to find anything explaining the necessity of wait_vdd in the documentation / elog and have only found so far your old forum posting, https://elog.psi.ch/elogs/DRS4+Forum/12
Does this forum posting explain wait_vdd or is there a another purpose that I have missed?
If this post is relevant to wait_vdd, does the advice of large capacitance and an LDO with fast transient response still apply or are there any new recommendations?
Thank you,
Andrew Peck
|
|
Mon Jun 24 23:07:35 2019, Andrew Peck, Evaluation firmware wait_vdd state
|
Dear Stefan,
Thanks so much for clarifying this. We made wait_vdd a parameter controlled by software and will try to experiment with it to find some compromise between deadtime and the offset added by the droop in VDD.
Best regards,
Andrew
Stefan Ritt wrote: |
Dear Andrew,
the posting you mention is still accurate. Any power supply will drop when you start the Domino wave, no matter how big your capacitor is. Unfortunately the output signal of the DRS4 scales with VDD. So if your VDD drops by 40 mV and you get a trigger and you immediately start the readout, the output baseline will also be shifted by about 40 mV. If you are sensitive to dead time, you can remove the wait_vdd state completely, but then you have to deal with varying baseline shifts. If you have narrow signals sitting on a broad baseline, you can correct for this by measuring the baseline outside your signal, then subtracting it before integrating your pulse. If you have lots of pile-up in your signals, it might sometimes be hard to evaluate the baseline on an event-by-event basis.
Stefan
Andrew Peck wrote: |
Dear Stefan,
I am working with others at UCLA on a custom made board built around the DRS4. We are in the process of writing firmware so I am adapting the readout state machine from the evaluation board firmware.
I see in the state machine of the eval board firmware that after a trigger is received, the FPGA goes into the start readout state and then into "wait_vdd", where the FPGA waits "~120 us for vdd to stabilize" before reading out the ADC.
Our application is sensitive to deadtime and this wait_vdd state adds very significantly. I am trying to find anything explaining the necessity of wait_vdd in the documentation / elog and have only found so far your old forum posting, https://elog.psi.ch/elogs/DRS4+Forum/12
Does this forum posting explain wait_vdd or is there a another purpose that I have missed?
If this post is relevant to wait_vdd, does the advice of large capacitance and an LDO with fast transient response still apply or are there any new recommendations?
Thank you,
Andrew Peck
|
|
|
Fri Apr 12 09:39:30 2019, Lev Pavlov, multi-board
|
Good afternoon, I use 5 boards in multi-mode, everything is connected according to the instructions. Can I measure the phase difference between the two signals on channel 1 and channel 20? with each board the phase shift is added +16 ns I can not figure out how to compensate for this. give thanks |
Fri Apr 12 09:55:50 2019, Stefan Ritt, multi-board
|
Subtract 16 ns from your measured value ;-)
Stefan
Lev Pavlov wrote: |
Good afternoon, I use 5 boards in multi-mode, everything is connected according to the instructions. Can I measure the phase difference between the two signals on channel 1 and channel 20? with each board the phase shift is added +16 ns I can not figure out how to compensate for this. give thanks
|
|
Fri Apr 12 09:59:15 2019, Lev Pavlov, multi-board
|
I understand this, thanks. But my Chief does not understand this, he wants to see the phase difference without “crutches”. And what is meant in the manual 50 ps resolution? Maybe I just do not understand something? And if you submit a reference signal not in the mode of a garland, but simultaneously in parallel to all the boards, will this shift go? Thanks
Lev Pavlov
Stefan Ritt wrote: |
Subtract 16 ns from your measured value ;-)
Stefan
Lev Pavlov wrote: |
Good afternoon, I use 5 boards in multi-mode, everything is connected according to the instructions. Can I measure the phase difference between the two signals on channel 1 and channel 20? with each board the phase shift is added +16 ns I can not figure out how to compensate for this. give thanks
|
|
|
Fri Apr 12 12:50:18 2019, Stefan Ritt, multi-board
|
If you have two signal going through two cables, the cable have never the same length (on a scale of picoseconds), and you have to calibrate that anyway. So a proper timing calibration is not a crutch.
What do you mean by "manual 50ps"? The manual does not mention any resolution. In my experience, you can achieve about 10ps between channels of the SAME board easily. The phase shift between boards in multi-mode is always there, unfortunately there are no cable which conduct current faster than the speed of light! What you can do is to split a common reference clock and send a copy to one channel of each board, then calculate the timing relative to the next edge in that reference signal. This way you get rid of the phase shift, but this is also a kind of calibration, so in your laguange that would be "a big crutch".
Stefan
Lev Pavlov wrote: |
I understand this, thanks. But my Chief does not understand this, he wants to see the phase difference without “crutches”. And what is meant in the manual 50 ps resolution? Maybe I just do not understand something? And if you submit a reference signal not in the mode of a garland, but simultaneously in parallel to all the boards, will this shift go? Thanks
Lev Pavlov
Stefan Ritt wrote: |
Subtract 16 ns from your measured value ;-)
Stefan
Lev Pavlov wrote: |
Good afternoon, I use 5 boards in multi-mode, everything is connected according to the instructions. Can I measure the phase difference between the two signals on channel 1 and channel 20? with each board the phase shift is added +16 ns I can not figure out how to compensate for this. give thanks
|
|
|
|
Thu Mar 14 03:43:49 2019, Deepak Samuel, How to buy DRS evaluation kit
|
Dear Stefan,
I have emailed drs4@psi.ch a couple of times regarding the pricing of the evaluation kits for academic use in India and have not received any reply and hence writing in this forum. Could you please help me in this?
Thanks and regards,
Deepak Samuel. |
Fri Mar 8 19:35:11 2019, Abaz Kryemadhi, ROOT Macro for newest software
|
The older root macro did not work for me for data acquired with the newest software.
so for the newest software and multiple boards, I modified the read_binary.cpp into read_binary.C for those who like to use the root macro, see the attachment.
|
Wed Mar 6 10:09:01 2019, Willy Chang, drscl "no board found" in some Win7 or Win8.X PCs
|
Hi all,
When connecting the board and running the Zadig program, some Windows PCs may return "driver installation failed." I coudn't find the solution from their download website. So I started the drscl first. Apparently it shows: Successfully scanned, but no boards found. Therefore I checked the Device Manager. A breakdown warning triangle appears under the serial port...
The possible solution may be found here.
Infact, the WinUsb driver has been in existence in your PC. One can just follow the instructions here:
https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/winusb-installation
- Plug in your device to the host system.
- Open Device Manager and locate the device.
- Right-click the device and select Update driver software... from the context menu.
- In the wizard, select Browse my computer for driver software.
- Select Let me pick from a list of device drivers on my computer.
- From the list of device classes, select Universal Serial Bus devices.
- The wizard displays WinUsb Device. Select it to load the driver.
In the wizard, somehow the default setting displays Microsoft Device on the Top of the list and replaced the WinUsb Device. You can easily re-load the WinUsb Device. Just ignore the WARNING from the device manager. The board should work fine now.
Willy |
Mon Feb 4 16:42:08 2019, Hans Steiger, Different Distances between the sampling points
|
Dear All,
with the older software for my V5 Board i did not have the problem, that the distance between the sampling points (in time) is not the same (e.g. a sampling point all 200ps for 5GS/s).
How can i fix this?
Can someone provide me the software for the board which is old enough to not have this problem. All my Root interpreters produce problems with this new data format. Which version would be old enough?
All the best and thanks a lot,
Hans |
Mon Feb 4 16:46:04 2019, Stefan Ritt, Different Distances between the sampling points
|
The sampling points are NOT equidestant, they have varying bin widths of 150ps to 250ps at 5GS/s. That's due the way the DRS4 chip works. You might have neglected that fact in the past, but that would have led to poor timing resolutions (typically 1-2ns resolution only). To get bins with the same width, you have to treat your waveform as a real X/Y points (or better U/T), and the re-sample that cure, maybe spline-interpolated, at 200ps bins.
Stefan
Hans Steiger wrote: |
Dear All,
with the older software for my V5 Board i did not have the problem, that the distance between the sampling points (in time) is not the same (e.g. a sampling point all 200ps for 5GS/s).
How can i fix this?
Can someone provide me the software for the board which is old enough to not have this problem. All my Root interpreters produce problems with this new data format. Which version would be old enough?
All the best and thanks a lot,
Hans
|
|
Mon Feb 4 17:36:49 2019, Hans Steiger, Different Distances between the sampling points
|
Sorry.... but is there a solution or a Root Macro, that reads the waveforms into a Root-Tree? I simply can not work anymore with the data.
Can you tell me, which software was in use in early 2017?
All the best,
Hans
Stefan Ritt wrote: |
The sampling points are NOT equidestant, they have varying bin widths of 150ps to 250ps at 5GS/s. That's due the way the DRS4 chip works. You might have neglected that fact in the past, but that would have led to poor timing resolutions (typically 1-2ns resolution only). To get bins with the same width, you have to treat your waveform as a real X/Y points (or better U/T), and the re-sample that cure, maybe spline-interpolated, at 200ps bins.
Stefan
Hans Steiger wrote: |
Dear All,
with the older software for my V5 Board i did not have the problem, that the distance between the sampling points (in time) is not the same (e.g. a sampling point all 200ps for 5GS/s).
How can i fix this?
Can someone provide me the software for the board which is old enough to not have this problem. All my Root interpreters produce problems with this new data format. Which version would be old enough?
All the best and thanks a lot,
Hans
|
|
|
Mon Feb 4 18:18:22 2019, Stefan Ritt, Different Distances between the sampling points
|
elog:361
Hans Steiger wrote: |
Sorry.... but is there a solution or a Root Macro, that reads the waveforms into a Root-Tree? I simply can not work anymore with the data.
Can you tell me, which software was in use in early 2017?
All the best,
Hans
Stefan Ritt wrote: |
The sampling points are NOT equidestant, they have varying bin widths of 150ps to 250ps at 5GS/s. That's due the way the DRS4 chip works. You might have neglected that fact in the past, but that would have led to poor timing resolutions (typically 1-2ns resolution only). To get bins with the same width, you have to treat your waveform as a real X/Y points (or better U/T), and the re-sample that cure, maybe spline-interpolated, at 200ps bins.
Stefan
Hans Steiger wrote: |
Dear All,
with the older software for my V5 Board i did not have the problem, that the distance between the sampling points (in time) is not the same (e.g. a sampling point all 200ps for 5GS/s).
How can i fix this?
Can someone provide me the software for the board which is old enough to not have this problem. All my Root interpreters produce problems with this new data format. Which version would be old enough?
All the best and thanks a lot,
Hans
|
|
|
|
Sat Feb 2 00:13:12 2019, Hans Steiger, Saving Rate (only 15Acq/s)
|
Dear All,
when I use my Evaluation Board with some PMTs I can digitize 450 Acq/s or so. But when I want to save the waveforms the rate goes down. The Acqu. rate with saving is in the range of 14Hz up to 24 Hz.
I normally use the .txt file. I try to use the 5GS/s but also with much lower sampling rate the saving rate is not getting much better.
Is this a problem of my McBook connected to the Evaluation Board?
All the best,
Hans |
Sat Feb 2 10:10:22 2019, Stefan Ritt, Saving Rate (only 15Acq/s)
|
The reduction of rate is because you save in XML format, which is an ASCII format, so human readable, but takes long to write. If you switch to binary format and write on a decent fast hard disk, you should get back to 450 Acq/s.
Stefan
Hans Steiger wrote: |
Dear All,
when I use my Evaluation Board with some PMTs I can digitize 450 Acq/s or so. But when I want to save the waveforms the rate goes down. The Acqu. rate with saving is in the range of 14Hz up to 24 Hz.
I normally use the .txt file. I try to use the 5GS/s but also with much lower sampling rate the saving rate is not getting much better.
Is this a problem of my McBook connected to the Evaluation Board?
All the best,
Hans
|
|
|