| ID |
Date |
Author |
Subject |
|
765
|
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
|
|
|
766
|
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
|
|
|
|
767
|
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
|
|
|
|
|
800
|
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 |
| Attachment 1: drs4_srin_srout_srclk.pdf
|
|
|
801
|
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
|
|
| Attachment 1: Screenshot_2020-10-27_at_13.45.39_.png
|
|
|
802
|
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
|
|
|
|
803
|
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
|
|
|
|
|
804
|
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
|
|
|
|
|
|
724
|
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 |
|
725
|
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 |
|
726
|
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 |
|
374
|
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.
|
|
376
|
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 |
|
539
|
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 |
|
540
|
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
|
|
|
623
|
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 |
|
624
|
Wed Jul 12 20:16:05 2017 |
Stefan Ritt | Time resolution between boards | Yes this should be possible.
Stefan
| Toshihiro Nonaka wrote: |
|
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
|
|
|
626
|
Fri Jul 21 09:16:02 2017 |
Volodymyr Rodin | Time output | Hello Stefan
I tried to convert binary to a simple txt file and found next problem - strange time output.
Here is output from little modification for read_binary.cpp (Its last output line also is strange: dT = -1.#IOns +- -1.$ps)
Found data for board #0
Found timing calibration for channel #1
Found boards# 1
event channel waveform time point
1 0 -0.000092 0.000000 0
1 0 0.030548 0.000000 1
1 0 0.059418 0.000000 2
1 0 0.080200 0.000000 3
1 0 0.094223 0.000000 4
1 0 0.097702 0.000000 5
1 0 0.094055 0.000000 6
1 0 0.079117 0.000000 7
1 0 0.060364 0.000000 8
1 0 0.030960 0.000000 9
1 0 0.000504 0.000000 10
1 0 -0.031555 0.000000 11
1 0 -0.057465 0.000000 12
1 0 -0.080536 0.000000 13
1 0 -0.095413 0.000000 14
1 0 -0.099365 0.000000 15
I used output string in the following places, but it didn't help:
// reach channel data
:for (i=0 ; i<1024 ; i++) {
// convert data to volts
waveform[0][chn_index][i] = (voltage[i] / 65536. + eh.range/1000.0 - 0.5);
// calculate time for this cell
for (j=0,time[b][chn_index][i]=0 ; j<i ; j++)
time[b][chn_index][i] += bin_width[b][chn_index][(j+tch.trigger_cell) % 1024];
printf("%10d %10d %10f %10f %10d\n", eh.event_serial_number , chn_index , waveform[0][chn_index][i] , time[0][chn_index][i] , i);
And after alignment procedure:
t1 = time[b][0][(1024-tch.trigger_cell) % 1024];
for (chn=1 ; chn<4 ; chn++) {
t2 = time[b][chn][(1024-tch.trigger_cell) % 1024];
dt = t1 - t2;
for (i=0 ; i<1024 ; i++)
time[b][chn][i] += dt;
printf("%10d %10d %10f %10f %10d\n", eh.event_serial_number , chn_index , waveform[0][chn_index][i] , time[0][chn][i] , i);
}
Does it caused by some software or drivers changes?
Best regards,
Volodymyr
|
|
627
|
Tue Jul 25 14:47:05 2017 |
Volodymyr Rodin | Time output | Hi again.
Okay, it works with 5.05 version very good and it is enough for me.
Besides,
What do I need to fix in this code for 2048 board?
Best wishes,
Volodymyr
| Volodymyr Rodin wrote: |
|
Hello Stefan
I tried to convert binary to a simple txt file and found next problem - strange time output.
Here is output from little modification for read_binary.cpp (Its last output line also is strange: dT = -1.#IOns +- -1.$ps)
Found data for board #0
Found timing calibration for channel #1
Found boards# 1
event channel waveform time point
1 0 -0.000092 0.000000 0
1 0 0.030548 0.000000 1
1 0 0.059418 0.000000 2
1 0 0.080200 0.000000 3
1 0 0.094223 0.000000 4
1 0 0.097702 0.000000 5
1 0 0.094055 0.000000 6
1 0 0.079117 0.000000 7
1 0 0.060364 0.000000 8
1 0 0.030960 0.000000 9
1 0 0.000504 0.000000 10
1 0 -0.031555 0.000000 11
1 0 -0.057465 0.000000 12
1 0 -0.080536 0.000000 13
1 0 -0.095413 0.000000 14
1 0 -0.099365 0.000000 15
I used output string in the following places, but it didn't help:
// reach channel data
:for (i=0 ; i<1024 ; i++) {
// convert data to volts
waveform[0][chn_index][i] = (voltage[i] / 65536. + eh.range/1000.0 - 0.5);
// calculate time for this cell
for (j=0,time[b][chn_index][i]=0 ; j<i ; j++)
time[b][chn_index][i] += bin_width[b][chn_index][(j+tch.trigger_cell) % 1024];
printf("%10d %10d %10f %10f %10d\n", eh.event_serial_number , chn_index , waveform[0][chn_index][i] , time[0][chn_index][i] , i);
And after alignment procedure:
t1 = time[b][0][(1024-tch.trigger_cell) % 1024];
for (chn=1 ; chn<4 ; chn++) {
t2 = time[b][chn][(1024-tch.trigger_cell) % 1024];
dt = t1 - t2;
for (i=0 ; i<1024 ; i++)
time[b][chn][i] += dt;
printf("%10d %10d %10f %10f %10d\n", eh.event_serial_number , chn_index , waveform[0][chn_index][i] , time[0][chn][i] , i);
}
Does it caused by some software or drivers changes?
Best regards,
Volodymyr
|
|
|
633
|
Tue Oct 17 14:58:58 2017 |
Vadym Denysenko | Time offset | Hello.
I have a simple question, can I set SetTriggerDelayNs() more than 1631 ns?
I need to set this delay to about 5 us... Can I do this?
Thank you in advance!
With best regards,
Vadym |
|