 Wed Sep 26 18:28:20 2018, Gerard Arino-Estrada, Trigger OUT pulse width variable from 100 us up to 100 ms
|
Thank you very much for the answer, I really appreciate your help.
Thanks!
Gerard
| Stefan Ritt wrote: |
|
The "Trigger OUT" has changed recently. It goes high on a new trigger, but then STAYS high until the board has been read out by the PC and re-started. This allows better synchronization with some external trigger, which can be re-armed with the falling edge of the trigger out signal. The signal can be quite long, since readout of an event via USB typically takes 2 ms, but can be more if the PC is busy. If you need back your 150 ns pulse, send the trigger out to an external pulse shaper with fixed shaping width.
Stefan
| Gerard Arino-Estrada wrote: |
|
Hello Stefan,
I am using the DRS4 board connected to a Raspberry PI and through the drsosc application. I am interested on using the "Trigger OUT" signal to do some extra data processing with NIM modules. According to the manual, for each hardware trigger a TTL pulse of 150 ns width should be send through the "trigger OUT". In my case I do see pulses with widths ranging from 100 microseconds up to hundreds of miliseconds. I am connecting the signal directly to an oscilloscope with 50 Ohm termination. I have tried two DRS4 boards in identical conditions and both show the same behavior. Having such wide and variable pulses makes it complicated for me to do the extra post-processing. Have you any idea of what might be going wrong? Thank you very much.
Best regards,
Gerard
|
|
|
|
Wed Sep 26 19:21:03 2018, Stefan Ritt, Trigger OUT pulse width variable from 100 us up to 100 ms
|
In meantime I even updated the manual.
Stefan
| Gerard Arino-Estrada wrote: |
|
Thank you very much for the answer, I really appreciate your help.
Thanks!
Gerard
|
|
|
Mon Dec 23 19:31:31 2024, Matias Henriquez, Trigger OUT pulse width variable from 100 us up to 100 ms
|
Given this new scenario, what is the maximum rate of events that can be processed then (a rough estimation would be great, 1/2ms?)? is it mainly limited by the USB data transmission and the PC? How does the logic of the trigger and DRS4 data sampling works inside the FPGA in general terms? e.g: trigger activated -> dwrite ON -> ADC acquisition -> busy until data has been shipped off to the PC -> free to process new events.
Is there a way to obtain some sort of timestamp for the trigger on each event? or is it better to use C++ time functions in the PC since the DRS4 is usually used in experiments with low rate of events so the long time it takes to the USB and PC is not a problem? (eg. particle physics).
Thanks for your help,
Matias H.
| Stefan Ritt wrote: |
|
The "Trigger OUT" has changed recently. It goes high on a new trigger, but then STAYS high until the board has been read out by the PC and re-started. This allows better synchronization with some external trigger, which can be re-armed with the falling edge of the trigger out signal. The signal can be quite long, since readout of an event via USB typically takes 2 ms, but can be more if the PC is busy. If you need back your 150 ns pulse, send the trigger out to an external pulse shaper with fixed shaping width.
Stefan
| Gerard Arino-Estrada wrote: |
|
Hello Stefan,
I am using the DRS4 board connected to a Raspberry PI and through the drsosc application. I am interested on using the "Trigger OUT" signal to do some extra data processing with NIM modules. According to the manual, for each hardware trigger a TTL pulse of 150 ns width should be send through the "trigger OUT". In my case I do see pulses with widths ranging from 100 microseconds up to hundreds of miliseconds. I am connecting the signal directly to an oscilloscope with 50 Ohm termination. I have tried two DRS4 boards in identical conditions and both show the same behavior. Having such wide and variable pulses makes it complicated for me to do the extra post-processing. Have you any idea of what might be going wrong? Thank you very much.
Best regards,
Gerard
|
|
|
 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
|
|
|
|
|
Wed Oct 21 15:03:13 2020, Seiya Nozaki, Timing diagram of SROUT/SRIN signal to write/read a write shift register
|
Dear Stefan,
I have questions about the timing diagram of SROUT/SRIN signal to write/read a write shift register.
1) Value of SRIN signal is saved at the falling edge of SRCLK, correct? (It is written in datasheet, page12, "Bits are latched into the shift register on the falling edge of SRCLK")
2) When are 8-bits of write shift register shown through SROUT? At ridging edges of SRCLK? and with additional delay(~10ns)? or falling edges?
3) In my understanding, when SRCLK is sent to DRS4, we can read and write the values in parallel, right? If so, is it possible just to read the registers without updating the registers?
[Background]
We have two modes to set the write shift register, the first one is to always reconnect to the first line and another one is to reconnect to the same line as when DWRITE goes to Low.
We can read/write the write shift register with the first mode (channel reset, page1). But we rarely face the problem of write shift register, unexpected values are written, with the second mode. With this mode, SROUT signal is sent back to DRS from FPGA as SRIN to write the same value on the write shift register. So there is a small delay(~10ns) due to the routing (DRS->FPGA->DRS, page2). It seems SRIN signal is not stable around the falling edges of SRCLK, thus it could cause that unexpected values are written in write shifter register.
To understand the situation clearly, I'd like to know the answer to the above questions.
Thank you.
Best regards,
Seiya |
|
Tue Oct 27 13:37:23 2020, Stefan Ritt, Timing diagram of SROUT/SRIN signal to write/read a write shift register
|
Dear Seiya,
1) That's correct. SRIN is ampled at the falling edge. Pleae make sure to obey the hold-time as written in the datasheet. P.12, Fig. 11: SRIN must be stable before the falling edge of SRCLK and tH after the falling clock. tH is 5ns according to table 1.
2) The write shift register is a 8-bit shift register, with an input, output and clock. After the first clock pulse, the 7th bit is shown, after the second clock pulse the 6th bit and so on. You you need 8 clock pulses to read the whole register. At the same time you write to the register, so what ever is present at SRIN will replace the old 8 bits of that register.
3) No this is not possible. When you read the register, you write to it at the same time. One possibilty is to connect SROUT to SRIN during that (maybe via the FPGA). Then you have a circular register wich is the same after each 8 clock pulses.
For your reference, I posted a commercial D-Flip Flop (TI SNHCS72). The DRS4 write shift register is a simple array of 8 such registers, with no CLR or PRE, where SROUT is Q of the last Flip Flop.
Best,
Stefan
| Seiya Nozaki wrote: |
|
Dear Stefan,
I have questions about the timing diagram of SROUT/SRIN signal to write/read a write shift register.
1) Value of SRIN signal is saved at the falling edge of SRCLK, correct? (It is written in datasheet, page12, "Bits are latched into the shift register on the falling edge of SRCLK")
2) When are 8-bits of write shift register shown through SROUT? At ridging edges of SRCLK? and with additional delay(~10ns)? or falling edges?
3) In my understanding, when SRCLK is sent to DRS4, we can read and write the values in parallel, right? If so, is it possible just to read the registers without updating the registers?
[Background]
We have two modes to set the write shift register, the first one is to always reconnect to the first line and another one is to reconnect to the same line as when DWRITE goes to Low.
We can read/write the write shift register with the first mode (channel reset, page1). But we rarely face the problem of write shift register, unexpected values are written, with the second mode. With this mode, SROUT signal is sent back to DRS from FPGA as SRIN to write the same value on the write shift register. So there is a small delay(~10ns) due to the routing (DRS->FPGA->DRS, page2). It seems SRIN signal is not stable around the falling edges of SRCLK, thus it could cause that unexpected values are written in write shifter register.
To understand the situation clearly, I'd like to know the answer to the above questions.
Thank you.
Best regards,
Seiya
|
|
|
Tue Oct 27 15:02:09 2020, Seiya Nozaki, Timing diagram of SROUT/SRIN signal to write/read a write shift register
|
Dear Stefan,
Thank you for your reply.
SRIN is directly connected to SROUT via FPGA for now, but it is unstable for the timing between clock and SRIN depending on the firmware logic.
We want to make our system more robust, so we are thinking to use a clock with a lower frequency (let's say 16.6 MHz) or change the duty cycle of a clock to keep more time between the rising edge and falling edge of a clock. This change is just for reading/writing the write shift register, we will use a 33 MHz clock for the analog readout in any case.
If we change like above, are there any concerns from the DRS4 side?
Best,
Seiya
| Stefan Ritt wrote: |
|
Dear Seiya,
1) That's correct. SRIN is ampled at the falling edge. Pleae make sure to obey the hold-time as written in the datasheet. P.12, Fig. 11: SRIN must be stable before the falling edge of SRCLK and tH after the falling clock. tH is 5ns according to table 1.
2) The write shift register is a 8-bit shift register, with an input, output and clock. After the first clock pulse, the 7th bit is shown, after the second clock pulse the 6th bit and so on. You you need 8 clock pulses to read the whole register. At the same time you write to the register, so what ever is present at SRIN will replace the old 8 bits of that register.
3) No this is not possible. When you read the register, you write to it at the same time. One possibilty is to connect SROUT to SRIN during that (maybe via the FPGA). Then you have a circular register wich is the same after each 8 clock pulses.
For your reference, I posted a commercial D-Flip Flop (TI SNHCS72). The DRS4 write shift register is a simple array of 8 such registers, with no CLR or PRE, where SROUT is Q of the last Flip Flop.
Best,
Stefan
| Seiya Nozaki wrote: |
|
Dear Stefan,
I have questions about the timing diagram of SROUT/SRIN signal to write/read a write shift register.
1) Value of SRIN signal is saved at the falling edge of SRCLK, correct? (It is written in datasheet, page12, "Bits are latched into the shift register on the falling edge of SRCLK")
2) When are 8-bits of write shift register shown through SROUT? At ridging edges of SRCLK? and with additional delay(~10ns)? or falling edges?
3) In my understanding, when SRCLK is sent to DRS4, we can read and write the values in parallel, right? If so, is it possible just to read the registers without updating the registers?
[Background]
We have two modes to set the write shift register, the first one is to always reconnect to the first line and another one is to reconnect to the same line as when DWRITE goes to Low.
We can read/write the write shift register with the first mode (channel reset, page1). But we rarely face the problem of write shift register, unexpected values are written, with the second mode. With this mode, SROUT signal is sent back to DRS from FPGA as SRIN to write the same value on the write shift register. So there is a small delay(~10ns) due to the routing (DRS->FPGA->DRS, page2). It seems SRIN signal is not stable around the falling edges of SRCLK, thus it could cause that unexpected values are written in write shifter register.
To understand the situation clearly, I'd like to know the answer to the above questions.
Thank you.
Best regards,
Seiya
|
|
|
|
Tue Oct 27 15:24:38 2020, Stefan Ritt, Timing diagram of SROUT/SRIN signal to write/read a write shift register
|
This is a static shift register, so you can make the clock as slow as you want. Actually I don't use a "clock", I just use a data pin I control via a state machine in the VHDL code. This way I have more control over the edges. I need several (internal) clock cycles to produce one SRCLK clock cycle, but that does not matter for the DRS.
Stefan
| Seiya Nozaki wrote: |
|
Dear Stefan,
Thank you for your reply.
SRIN is directly connected to SROUT via FPGA for now, but it is unstable for the timing between clock and SRIN depending on the firmware logic.
We want to make our system more robust, so we are thinking to use a clock with a lower frequency (let's say 16.6 MHz) or change the duty cycle of a clock to keep more time between the rising edge and falling edge of a clock. This change is just for reading/writing the write shift register, we will use a 33 MHz clock for the analog readout in any case.
If we change like above, are there any concerns from the DRS4 side?
Best,
Seiya
| Stefan Ritt wrote: |
|
Dear Seiya,
1) That's correct. SRIN is ampled at the falling edge. Pleae make sure to obey the hold-time as written in the datasheet. P.12, Fig. 11: SRIN must be stable before the falling edge of SRCLK and tH after the falling clock. tH is 5ns according to table 1.
2) The write shift register is a 8-bit shift register, with an input, output and clock. After the first clock pulse, the 7th bit is shown, after the second clock pulse the 6th bit and so on. You you need 8 clock pulses to read the whole register. At the same time you write to the register, so what ever is present at SRIN will replace the old 8 bits of that register.
3) No this is not possible. When you read the register, you write to it at the same time. One possibilty is to connect SROUT to SRIN during that (maybe via the FPGA). Then you have a circular register wich is the same after each 8 clock pulses.
For your reference, I posted a commercial D-Flip Flop (TI SNHCS72). The DRS4 write shift register is a simple array of 8 such registers, with no CLR or PRE, where SROUT is Q of the last Flip Flop.
Best,
Stefan
| Seiya Nozaki wrote: |
|
Dear Stefan,
I have questions about the timing diagram of SROUT/SRIN signal to write/read a write shift register.
1) Value of SRIN signal is saved at the falling edge of SRCLK, correct? (It is written in datasheet, page12, "Bits are latched into the shift register on the falling edge of SRCLK")
2) When are 8-bits of write shift register shown through SROUT? At ridging edges of SRCLK? and with additional delay(~10ns)? or falling edges?
3) In my understanding, when SRCLK is sent to DRS4, we can read and write the values in parallel, right? If so, is it possible just to read the registers without updating the registers?
[Background]
We have two modes to set the write shift register, the first one is to always reconnect to the first line and another one is to reconnect to the same line as when DWRITE goes to Low.
We can read/write the write shift register with the first mode (channel reset, page1). But we rarely face the problem of write shift register, unexpected values are written, with the second mode. With this mode, SROUT signal is sent back to DRS from FPGA as SRIN to write the same value on the write shift register. So there is a small delay(~10ns) due to the routing (DRS->FPGA->DRS, page2). It seems SRIN signal is not stable around the falling edges of SRCLK, thus it could cause that unexpected values are written in write shifter register.
To understand the situation clearly, I'd like to know the answer to the above questions.
Thank you.
Best regards,
Seiya
|
|
|
|
|
Wed Oct 28 04:32:19 2020, Seiya Nozaki, Timing diagram of SROUT/SRIN signal to write/read a write shift register
|
Dear Stefan,
OK, it's good to hear! Thank you!
Best,
Seiya
| Stefan Ritt wrote: |
|
This is a static shift register, so you can make the clock as slow as you want. Actually I don't use a "clock", I just use a data pin I control via a state machine in the VHDL code. This way I have more control over the edges. I need several (internal) clock cycles to produce one SRCLK clock cycle, but that does not matter for the DRS.
Stefan
| Seiya Nozaki wrote: |
|
Dear Stefan,
Thank you for your reply.
SRIN is directly connected to SROUT via FPGA for now, but it is unstable for the timing between clock and SRIN depending on the firmware logic.
We want to make our system more robust, so we are thinking to use a clock with a lower frequency (let's say 16.6 MHz) or change the duty cycle of a clock to keep more time between the rising edge and falling edge of a clock. This change is just for reading/writing the write shift register, we will use a 33 MHz clock for the analog readout in any case.
If we change like above, are there any concerns from the DRS4 side?
Best,
Seiya
| Stefan Ritt wrote: |
|
Dear Seiya,
1) That's correct. SRIN is ampled at the falling edge. Pleae make sure to obey the hold-time as written in the datasheet. P.12, Fig. 11: SRIN must be stable before the falling edge of SRCLK and tH after the falling clock. tH is 5ns according to table 1.
2) The write shift register is a 8-bit shift register, with an input, output and clock. After the first clock pulse, the 7th bit is shown, after the second clock pulse the 6th bit and so on. You you need 8 clock pulses to read the whole register. At the same time you write to the register, so what ever is present at SRIN will replace the old 8 bits of that register.
3) No this is not possible. When you read the register, you write to it at the same time. One possibilty is to connect SROUT to SRIN during that (maybe via the FPGA). Then you have a circular register wich is the same after each 8 clock pulses.
For your reference, I posted a commercial D-Flip Flop (TI SNHCS72). The DRS4 write shift register is a simple array of 8 such registers, with no CLR or PRE, where SROUT is Q of the last Flip Flop.
Best,
Stefan
| Seiya Nozaki wrote: |
|
Dear Stefan,
I have questions about the timing diagram of SROUT/SRIN signal to write/read a write shift register.
1) Value of SRIN signal is saved at the falling edge of SRCLK, correct? (It is written in datasheet, page12, "Bits are latched into the shift register on the falling edge of SRCLK")
2) When are 8-bits of write shift register shown through SROUT? At ridging edges of SRCLK? and with additional delay(~10ns)? or falling edges?
3) In my understanding, when SRCLK is sent to DRS4, we can read and write the values in parallel, right? If so, is it possible just to read the registers without updating the registers?
[Background]
We have two modes to set the write shift register, the first one is to always reconnect to the first line and another one is to reconnect to the same line as when DWRITE goes to Low.
We can read/write the write shift register with the first mode (channel reset, page1). But we rarely face the problem of write shift register, unexpected values are written, with the second mode. With this mode, SROUT signal is sent back to DRS from FPGA as SRIN to write the same value on the write shift register. So there is a small delay(~10ns) due to the routing (DRS->FPGA->DRS, page2). It seems SRIN signal is not stable around the falling edges of SRCLK, thus it could cause that unexpected values are written in write shifter register.
To understand the situation clearly, I'd like to know the answer to the above questions.
Thank you.
Best regards,
Seiya
|
|
|
|
|
|
Thu Nov 8 11:44:35 2018, Davide Depaoli, Timing Issue
|
Hi,
We are using the DRS4 Evaluation Board as a digitizer in our laboratory.
We found a strange behavior in the saved files, more specifically the time difference between two consecutive points is not constant, also after the Timing Calibration.
As an example, I paste a piece of a xml file saved using the drsosc program, acquiring CH1 (open):
---------------------------
---[ START XML EXAMPLE ]---
---------------------------
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- created by MXML on Thu Nov 8 11:13:27 2018 -->
<DRSOSC>
<Event>
<Serial>1</Serial>
<Time>2018/11/08 11:13:27.163</Time>
<HUnit>ns</HUnit>
<VUnit>mV</VUnit>
<Board_2796>
<Trigger_Cell>216</Trigger_Cell>
<Scaler0>0</Scaler0>
<CHN1>
<Data>0.000,-1.0</Data>
<Data>1.083,-1.0</Data>
<Data>2.143,-1.0</Data>
<Data>2.926,-1.0</Data>
<Data>4.249,-0.1</Data>
<Data>4.929,-0.6</Data>
<Data>6.075,-0.4</Data>
<Data>7.042,0.0</Data>
<Data>8.299,0.2</Data>
[...]
-------------------------
---[ END XML EXAMPLE ]---
-------------------------
We found the same behavior saving events in the binary format, and then reading them with the read_binary.cpp
Is there a way to fix our issue?
Thanks a lot
Davide and Alessio |
|
Thu Nov 8 11:54:33 2018, Stefan Ritt, Timing Issue
|
That's not a bug, but a feature of the DRS4 chip. The time bins have different values by the properties of the chip. They are generated by a chain of inverters, which all have different propagation times. This delay is measured by the time calibration and then applied. If you want equidistant bins,
you have to interpolate your data points (linearly or by splines) and resample the signal. You can find more details in the DRS4 data sheet.
Best,
Stefan
> Hi,
>
> We are using the DRS4 Evaluation Board as a digitizer in our laboratory.
> We found a strange behavior in the saved files, more specifically the time difference between two consecutive points is not constant, also after the Timing Calibration.
> As an example, I paste a piece of a xml file saved using the drsosc program, acquiring CH1 (open):
>
> ---------------------------
> ---[ START XML EXAMPLE ]---
> ---------------------------
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <!-- created by MXML on Thu Nov 8 11:13:27 2018 -->
> <DRSOSC>
> <Event>
> <Serial>1</Serial>
> <Time>2018/11/08 11:13:27.163</Time>
> <HUnit>ns</HUnit>
> <VUnit>mV</VUnit>
> <Board_2796>
> <Trigger_Cell>216</Trigger_Cell>
> <Scaler0>0</Scaler0>
> <CHN1>
> <Data>0.000,-1.0</Data>
> <Data>1.083,-1.0</Data>
> <Data>2.143,-1.0</Data>
> <Data>2.926,-1.0</Data>
> <Data>4.249,-0.1</Data>
> <Data>4.929,-0.6</Data>
> <Data>6.075,-0.4</Data>
> <Data>7.042,0.0</Data>
> <Data>8.299,0.2</Data>
>
> [...]
>
> -------------------------
> ---[ END XML EXAMPLE ]---
> -------------------------
>
> We found the same behavior saving events in the binary format, and then reading them with the read_binary.cpp
>
> Is there a way to fix our issue?
>
> Thanks a lot
>
> Davide and Alessio |
|
Thu Nov 8 12:02:34 2018, Davide Depaoli, Timing Issue
|
Thanks a lot for the quick response.
We will do as you suggest.
Best regards
Davide and Alessio
> That's not a bug, but a feature of the DRS4 chip. The time bins have different values by the properties of the chip. They are generated by a chain of inverters, which all have different
propagation times. This delay is measured by the time calibration and then applied. If you want equidistant bins,
> you have to interpolate your data points (linearly or by splines) and resample the signal. You can find more details in the DRS4 data sheet.
>
> Best,
> Stefan
>
>
> > Hi,
> >
> > We are using the DRS4 Evaluation Board as a digitizer in our laboratory.
> > We found a strange behavior in the saved files, more specifically the time difference between two consecutive points is not constant, also after the Timing Calibration.
> > As an example, I paste a piece of a xml file saved using the drsosc program, acquiring CH1 (open):
> >
> > ---------------------------
> > ---[ START XML EXAMPLE ]---
> > ---------------------------
> >
> > <?xml version="1.0" encoding="ISO-8859-1"?>
> > <!-- created by MXML on Thu Nov 8 11:13:27 2018 -->
> > <DRSOSC>
> > <Event>
> > <Serial>1</Serial>
> > <Time>2018/11/08 11:13:27.163</Time>
> > <HUnit>ns</HUnit>
> > <VUnit>mV</VUnit>
> > <Board_2796>
> > <Trigger_Cell>216</Trigger_Cell>
> > <Scaler0>0</Scaler0>
> > <CHN1>
> > <Data>0.000,-1.0</Data>
> > <Data>1.083,-1.0</Data>
> > <Data>2.143,-1.0</Data>
> > <Data>2.926,-1.0</Data>
> > <Data>4.249,-0.1</Data>
> > <Data>4.929,-0.6</Data>
> > <Data>6.075,-0.4</Data>
> > <Data>7.042,0.0</Data>
> > <Data>8.299,0.2</Data>
> >
> > [...]
> >
> > -------------------------
> > ---[ END XML EXAMPLE ]---
> > -------------------------
> >
> > We found the same behavior saving events in the binary format, and then reading them with the read_binary.cpp
> >
> > Is there a way to fix our issue?
> >
> > Thanks a lot
> >
> > Davide and Alessio |
|
Mon Sep 15 16:24:41 2014, Hannes Wachter, Timing Calibration Fail
|
Hi,
has anyone experienced a shutdown of the DRSosc.exe or DRScl.exe when executing a Timing Calibration? Also, when we add the command b->CalibrateTiming(NULL); to the drs_exam.cpp and run the exe, our program shuts down immediately and windows shows an error message (identical to DRSosc and DRScl).
Any help is appreciated.
|
|
Mon Sep 22 15:04:37 2014, Stefan Ritt, Timing Calibration Fail
|
| Hannes Wachter wrote: |
|
Hi,
has anyone experienced a shutdown of the DRSosc.exe or DRScl.exe when executing a Timing Calibration? Also, when we add the command b->CalibrateTiming(NULL); to the drs_exam.cpp and run the exe, our program shuts down immediately and windows shows an error message (identical to DRSosc and DRScl).
Any help is appreciated.
|
Actually there is no need to call b->CalibrateTiming() at all from drs_exam.cpp. The timing calibration, once executed, will remain valid over a wide temperature range and for very long time (years), so no need to redo it over and over again.
/Stefan |
|
Wed Oct 5 22:43:29 2016, Will Flanagan, Timestamp for each DRS4 waveform
|
Hi DRS4 Experts,
I have been analyzing DRS4 binary data with scripts based on Stefan's (very helpful!) macro:
https://midas.psi.ch/elogs/DRS4+Forum/361
I would now like to look at the stability of my waveforms over a long period of time. In order to do this, I would need a timestamp encoded with each waveform. Are there timestamps within default DRS4 binary data? If so, does anyone have sample code for extracting them?
Best Regards,
Will |
|
Thu Oct 6 11:18:05 2016, Stefan Ritt, Timestamp for each DRS4 waveform
|
In the mentioned read_binary.cpp file you have the line where you read the event header
i = fread(&eh, sizeof(eh), 1, f);
The C structure eh now contains the full timestamp, and you can access it with
eh.year
eh.month
eh.day
eh.hour
eh.minute
eh.second
eh.millisecond
Cheers,
Stefan
| Will Flanagan wrote: |
|
Hi DRS4 Experts,
I have been analyzing DRS4 binary data with scripts based on Stefan's (very helpful!) macro:
https://midas.psi.ch/elogs/DRS4+Forum/361
I would now like to look at the stability of my waveforms over a long period of time. In order to do this, I would need a timestamp encoded with each waveform. Are there timestamps within default DRS4 binary data? If so, does anyone have sample code for extracting them?
Best Regards,
Will
|
|
|
Wed Jul 12 04:24:39 2017, Toshihiro Nonaka, Time resolution between boards
|
Hello,
I 'm using four evaluation boards v.3 to construct the multi-board DAQ system. One channel for each board is used as reference clock, then calibrate timing offline, which allow below 10ps resolution between boards.
Is it possible to keep the time resolution between boards below 10ps in daisy-chain mode with v.5 boards?
Thank you in adcance.
Best regards,
Toshihiro Nonaka |
|