Thu Jul 6 15:10:48 2017, Esperienza Giove, Trigger setting (AND AND) OR (AND AND)
|
Hello there,
is it possible to setup trigger in double AND configuration (a pair in and or other pair in and).
eg (CH 1 AND CH 2 ) OR ( CH 3 AND CH4)
Thank you |
Fri Jul 7 10:31:47 2017, Stefan Ritt, Trigger setting (AND AND) OR (AND AND)
|
Unfortunately not with the current firmware.
Stefan
Esperienza Giove wrote: |
Hello there,
is it possible to setup trigger in double AND configuration (a pair in and or other pair in and).
eg (CH 1 AND CH 2 ) OR ( CH 3 AND CH4)
Thank you
|
|
Thu Jun 8 14:26:23 2017, Rebecca Schmitz, AND Trigger problems with 2-3 channels
|
Hello,
I work with the DRS4 Evaluation Board V5 and I have a problem with the software.
I have a problem with the AND trigger setting.
For this I have chosen the AND trigger function. However, when ONE channel senses an impulse, it triggers. I'm not able to see signals in the other channels, which I selected for the coincidence.
What is the cause of this? Maybe the time window?
I would like to measure a coincidence with two or three random channels. Is it possible?
Thanks for the help.
Rebecca |
Thu Jun 8 15:52:20 2017, Stefan Ritt, AND Trigger problems with 2-3 channels
|
Can you post a screenshot where I can see the channel waveforms, the configuration and the trigger settings?
Stefan
Rebecca Schmitz wrote: |
Hello,
I work with the DRS4 Evaluation Board V5 and I have a problem with the software.
I have a problem with the AND trigger setting.
For this I have chosen the AND trigger function. However, when ONE channel senses an impulse, it triggers. I'm not able to see signals in the other channels, which I selected for the coincidence.
What is the cause of this? Maybe the time window?
I would like to measure a coincidence with two or three random channels. Is it possible?
Thanks for the help.
Rebecca
|
|
Fri Jun 9 09:44:33 2017, Rebecca Schmitz, AND Trigger problems with 2-3 channels
|
Hello,
It seems that a coincidence with two fixed channels suddenly works. I don't know why.
Screenshot 1 shows the trigger settings for the coincidence with two channels.
Screenshot 2 shows the oscilloscope surface.
Screenshot 3 shows the configuration. In the background there is a coincidence with three channels.
In contrast to the coincidence with two channels this doesn't look good.
Rebecca
Stefan Ritt wrote: |
Can you post a screenshot where I can see the channel waveforms, the configuration and the trigger settings?
Stefan
Rebecca Schmitz wrote: |
Hello,
I work with the DRS4 Evaluation Board V5 and I have a problem with the software.
I have a problem with the AND trigger setting.
For this I have chosen the AND trigger function. However, when ONE channel senses an impulse, it triggers. I'm not able to see signals in the other channels, which I selected for the coincidence.
What is the cause of this? Maybe the time window?
I would like to measure a coincidence with two or three random channels. Is it possible?
Thanks for the help.
Rebecca
|
|
|
Thu Jun 22 21:36:08 2017, Stefan Ritt, AND Trigger problems with 2-3 channels
|
Hi,
from our screenshots I see the following:
- you have sometimes a huge oscillation in your preamplifier. Fix this first before doing any waveform recording
- your signals are barely 20 mV, and your trigger threshold is 20 mV. The coincidence only triggers when both signals are below the trigger threshold at the same time, and the overlap must be longer than 4-5 ns. So if your signals are not exactly in time, you won't get a coincidence trigger
Stefan
Rebecca Schmitz wrote: |
Hello,
It seems that a coincidence with two fixed channels suddenly works. I don't know why.
Screenshot 1 shows the trigger settings for the coincidence with two channels.
Screenshot 2 shows the oscilloscope surface.
Screenshot 3 shows the configuration. In the background there is a coincidence with three channels.
In contrast to the coincidence with two channels this doesn't look good.
Rebecca
Stefan Ritt wrote: |
Can you post a screenshot where I can see the channel waveforms, the configuration and the trigger settings?
Stefan
Rebecca Schmitz wrote: |
Hello,
I work with the DRS4 Evaluation Board V5 and I have a problem with the software.
I have a problem with the AND trigger setting.
For this I have chosen the AND trigger function. However, when ONE channel senses an impulse, it triggers. I'm not able to see signals in the other channels, which I selected for the coincidence.
What is the cause of this? Maybe the time window?
I would like to measure a coincidence with two or three random channels. Is it possible?
Thanks for the help.
Rebecca
|
|
|
|
Tue May 30 20:45:30 2017, Esperienza Giove, Setting input range
|
Hello,
is it possible to set a completely negative input range like -1 to 0 or -0.95 to 0.05 ? |
Tue May 30 21:00:26 2017, Stefan Ritt, Setting input range
|
See elog:531
Esperienza Giove wrote: |
Hello,
is it possible to set a completely negative input range like -1 to 0 or -0.95 to 0.05 ?
|
|
Tue May 30 21:22:10 2017, Esperienza Giove, Setting input range
|
Thank you
Stefan Ritt wrote: |
See elog:531
Esperienza Giove wrote: |
Hello,
is it possible to set a completely negative input range like -1 to 0 or -0.95 to 0.05 ?
|
|
|
Mon May 22 18:27:56 2017, Esperienza Giove, Invalid magic number 0000
|
Hello everybody!
After some times i init my board, or if i stop the program during the acquisition, i get the error message "Invalid magic 0000". The only way i can solve this problem is to physically disconnect and plug in again the USB cable.
What's the point? Is there a bash command / code i could use to reset it?
Thank you very much |
Tue May 23 10:24:47 2017, Stefan Ritt, Invalid magic number 0000
|
Under linux, many people observed that the USB connection is unstable to the evaluation board. This must be related to the linux USB stack, since my code runs fine under MacOSX and Windows, where I use the same USB library (libusb-1.0). So I can't do anything from my side. Baybe the linux system has some tools to reset an USB endpoint. I googled it and found some proposals here:
https://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line
Regards,
Stefan
Esperienza Giove wrote: |
Hello everybody!
After some times i init my board, or if i stop the program during the acquisition, i get the error message "Invalid magic 0000". The only way i can solve this problem is to physically disconnect and plug in again the USB cable.
What's the point? Is there a bash command / code i could use to reset it?
Thank you very much
|
|
Thu May 25 20:17:41 2017, Esperienza Giove, Invalid magic number 0000
|
Hello, thanks for your answer. Unluckily if i try to reset in this way it keeps hanging
musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0
musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0
Invalid magic number: 0000
musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0
musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0
I also tried with sudo tee /sys/bus/usb/drivers/usb/unbind and binding again; same thing happens. It seems the board needs to be reset when this happens. Is there a way to do that - to reset the board instead of usb?
Thank you
Stefan Ritt wrote:
|
Under linux, many people observed that the USB connection is unstable to the evaluation board. This must be related to the linux USB stack, since my code runs fine under MacOSX and Windows, where I use the same USB library (libusb-1.0). So I can't do anything from my side. Baybe the linux system has some tools to reset an USB endpoint. I googled it and found some proposals here:
https://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line
Regards,
Stefan
Esperienza Giove wrote: |
Hello everybody!
After some times i init my board, or if i stop the program during the acquisition, i get the error message "Invalid magic 0000". The only way i can solve this problem is to physically disconnect and plug in again the USB cable.
What's the point? Is there a bash command / code i could use to reset it?
Thank you very much
|
|
|
Fri May 26 08:48:25 2017, Stefan Ritt, Invalid magic number 0000
|
There is no other way to reset the board. As I said, people running this under Windows or MacOS are fine, so maybe this calls for a change of OS.
Esperienza Giove wrote: |
Hello, thanks for your answer. Unluckily if i try to reset in this way it keeps hanging
musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0
musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0
Invalid magic number: 0000
musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0
musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0
I also tried with sudo tee /sys/bus/usb/drivers/usb/unbind and binding again; same thing happens. It seems the board needs to be reset when this happens. Is there a way to do that - to reset the board instead of usb?
Thank you
Stefan Ritt wrote:
|
Under linux, many people observed that the USB connection is unstable to the evaluation board. This must be related to the linux USB stack, since my code runs fine under MacOSX and Windows, where I use the same USB library (libusb-1.0). So I can't do anything from my side. Baybe the linux system has some tools to reset an USB endpoint. I googled it and found some proposals here:
https://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line
Regards,
Stefan
Esperienza Giove wrote: |
Hello everybody!
After some times i init my board, or if i stop the program during the acquisition, i get the error message "Invalid magic 0000". The only way i can solve this problem is to physically disconnect and plug in again the USB cable.
What's the point? Is there a bash command / code i could use to reset it?
Thank you very much
|
|
|
|
Thu May 25 20:20:57 2017, Esperienza Giove, Invalid magic number 0000
|
Hello, thanks for your answer. Unluckily if i try to reset in this way it keeps hanging
musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0
musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0
Invalid magic number: 0000
musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0
musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0
I also tried with sudo tee /sys/bus/usb/drivers/usb/unbind and binding again; same thing happens. It seems the board needs to be reset when this happens. Is there a way to do that - to reset the board instead of usb?
Thank you
Stefan Ritt wrote:
|
Under linux, many people observed that the USB connection is unstable to the evaluation board. This must be related to the linux USB stack, since my code runs fine under MacOSX and Windows, where I use the same USB library (libusb-1.0). So I can't do anything from my side. Baybe the linux system has some tools to reset an USB endpoint. I googled it and found some proposals here:
https://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line
Regards,
Stefan
Esperienza Giove wrote: |
Hello everybody!
After some times i init my board, or if i stop the program during the acquisition, i get the error message "Invalid magic 0000". The only way i can solve this problem is to physically disconnect and plug in again the USB cable.
What's the point? Is there a bash command / code i could use to reset it?
Thank you very much
|
|
|
Sat Apr 15 03:48:31 2017, Strahinja Lukic, Wave rotation during transfer from the board?
|
I don't know if this question is already documented elsewhere.
I am developing a DAQ code for the DRS evaluation board, v4 for a test beam experiment. I link parts of the existing DRS code as a library.
To understand the effect of various flags used in calls to the functions DRSBoard::GetTime() and DRSBoard::GetWave(), I performed several tests with the 100 MHz signal connected to the inputs of the chip (DRSBoard::EnableTcal()), and several tests with signals from scintillation counters.
My question is about the flag "adjustToClock" in the call to DRSBoard::GetWave(). From looking at the code, I expected it to cause the waveforms to be "rotated" to start from the trigger cell, in a similar way that the flag "rotated" in the call to DRSBoard::GetTime() does for the time array. However, "adjustToClock" seems to shift the waveforms wrongly. I.e., if I want both the time and the amplitude arrays "rotated" to start from the trigger cell, I should set rotated=true for time and adjustToClock=false for the amplitude. This is also how these functions are called in e.g., Osci::ReadWaveforms().
Is this correct, and does this mean that the amplitude array is "rotated" already during the transfer from the board?
I am using DRS evaluation board serial #2733, firmware revision 30000.
Many thanks,
Strahinja
|
Wed Apr 19 12:17:25 2017, Stefan Ritt, Wave rotation during transfer from the board?
|
This is correct. Actually the amplitude array is rotated already inside the DRS4 chip. So the readout starts with the stop cell plus one. If you do not do anything, the waveform is already "rotated". If you want the waveform to start with physical cell #0, you have to "unrotate" it.
Stefan
Strahinja Lukic wrote: |
Is this correct, and does this mean that the amplitude array is "rotated" already during the transfer from the board?
|
|
Thu Apr 20 06:30:13 2017, Strahinja Lukic, Wave rotation during transfer from the board?
|
Thanks.
Strahinja
Stefan Ritt wrote: |
This is correct. Actually the amplitude array is rotated already inside the DRS4 chip. So the readout starts with the stop cell plus one. If you do not do anything, the waveform is already "rotated". If you want the waveform to start with physical cell #0, you have to "unrotate" it.
Stefan
Strahinja Lukic wrote: |
Is this correct, and does this mean that the amplitude array is "rotated" already during the transfer from the board?
|
|
|
Thu Apr 13 16:42:21 2017, Christian Farina, Stand-alone Time Calibration for PSI Board
|
Hello everybody,
I was trying to create a stand-alone program that would perform a time calibration on the board. My goal would be the following.
- acquire about 10k sinus waveforms
- write them to disk (also for later reanalysis)
- run the time calibration on the recorded data
- store the clibration results in a file / database
Being not an expert, my question here is the following. Would it be easier to try to isolate the time calibration part from the DRS.cpp source code or re-write entirely the code from scratch?
Thanks. |
Thu Apr 13 16:50:18 2017, Stefan Ritt, Stand-alone Time Calibration for PSI Board
|
Hard to say. Timing calibration is quite delicate. If you start from scratch, better read this paper: https://arxiv.org/abs/1405.4975
If you try to extract the code from DRS.cpp, better read the paper, too. Probably it will not be possible to develop or extract the code without knowing how it works.
Best,
Stefan
Christian Farina wrote: |
Hello everybody,
I was trying to create a stand-alone program that would perform a time calibration on the board. My goal would be the following.
- acquire about 10k sinus waveforms
- write them to disk (also for later reanalysis)
- run the time calibration on the recorded data
- store the clibration results in a file / database
Being not an expert, my question here is the following. Would it be easier to try to isolate the time calibration part from the DRS.cpp source code or re-write entirely the code from scratch?
Thanks.
|
|
Thu Apr 13 16:54:32 2017, Christian Farina, Stand-alone Time Calibration for PSI Board
|
Hi Stefan,
Thank you for your reply. I have read the paper already. I looked through the code and I understand that the LTC and GTC are performed by the AnalyzeSlope and AnalyzePeriod functions, respectively, correct? It seems to me to be a complicated business to re-write that part from scratch, at least for an inexperienced programmer like me. It made more sense to try to isolate that part from the original DRS.cpp. Ideally, I would like to have a stand-alone program that would work on any SCA without references to the drs hardware specifics.
Stefan Ritt wrote: |
Hard to say. Timing calibration is quite delicate. If you start from scratch, better read this paper: https://arxiv.org/abs/1405.4975
If you try to extract the code from DRS.cpp, better read the paper, too. Probably it will not be possible to develop or extract the code without knowing how it works.
Best,
Stefan
Christian Farina wrote: |
Hello everybody,
I was trying to create a stand-alone program that would perform a time calibration on the board. My goal would be the following.
- acquire about 10k sinus waveforms
- write them to disk (also for later reanalysis)
- run the time calibration on the recorded data
- store the clibration results in a file / database
Being not an expert, my question here is the following. Would it be easier to try to isolate the time calibration part from the DRS.cpp source code or re-write entirely the code from scratch?
Thanks.
|
|
|
Thu Apr 13 17:02:01 2017, Stefan Ritt, Stand-alone Time Calibration for PSI Board
|
Than you can try to isolate the code. Note that different SCAs might work differently. Like the DRS4 has a channel-to-channel jitter which others might not. But you will see.
Stefan
Christian Farina wrote: |
Hi Stefan,
Thank you for your reply. I have read the paper already. I looked through the code and I understand that the LTC and GTC are performed by the AnalyzeSlope and AnalyzePeriod functions, respectively, correct? It seems to me to be a complicated business to re-write that part from scratch, at least for an inexperienced programmer like me. It made more sense to try to isolate that part from the original DRS.cpp. Ideally, I would like to have a stand-alone program that would work on any SCA without references to the drs hardware specifics.
Stefan Ritt wrote: |
Hard to say. Timing calibration is quite delicate. If you start from scratch, better read this paper: https://arxiv.org/abs/1405.4975
If you try to extract the code from DRS.cpp, better read the paper, too. Probably it will not be possible to develop or extract the code without knowing how it works.
Best,
Stefan
Christian Farina wrote: |
Hello everybody,
I was trying to create a stand-alone program that would perform a time calibration on the board. My goal would be the following.
- acquire about 10k sinus waveforms
- write them to disk (also for later reanalysis)
- run the time calibration on the recorded data
- store the clibration results in a file / database
Being not an expert, my question here is the following. Would it be easier to try to isolate the time calibration part from the DRS.cpp source code or re-write entirely the code from scratch?
Thanks.
|
|
|
|
Thu Apr 13 17:10:58 2017, Christian Farina, Stand-alone Time Calibration for PSI Board
|
Thank you for your help Stefan. I will try to get the TC part isolated.
Stefan Ritt wrote: |
Than you can try to isolate the code. Note that different SCAs might work differently. Like the DRS4 has a channel-to-channel jitter which others might not. But you will see.
Stefan
Christian Farina wrote: |
Hi Stefan,
Thank you for your reply. I have read the paper already. I looked through the code and I understand that the LTC and GTC are performed by the AnalyzeSlope and AnalyzePeriod functions, respectively, correct? It seems to me to be a complicated business to re-write that part from scratch, at least for an inexperienced programmer like me. It made more sense to try to isolate that part from the original DRS.cpp. Ideally, I would like to have a stand-alone program that would work on any SCA without references to the drs hardware specifics.
Stefan Ritt wrote: |
Hard to say. Timing calibration is quite delicate. If you start from scratch, better read this paper: https://arxiv.org/abs/1405.4975
If you try to extract the code from DRS.cpp, better read the paper, too. Probably it will not be possible to develop or extract the code without knowing how it works.
Best,
Stefan
Christian Farina wrote: |
Hello everybody,
I was trying to create a stand-alone program that would perform a time calibration on the board. My goal would be the following.
- acquire about 10k sinus waveforms
- write them to disk (also for later reanalysis)
- run the time calibration on the recorded data
- store the clibration results in a file / database
Being not an expert, my question here is the following. Would it be easier to try to isolate the time calibration part from the DRS.cpp source code or re-write entirely the code from scratch?
Thanks.
|
|
|
|
|
Mon Apr 10 08:50:11 2017, Giovanni Bruni, drs4 registers behaviour
|
Hej everyone!
I have some questions regarding what happens to some DRS registers in some scenarios:
1. How are the registers affected by a RESET? According to the data sheet all the CONFIG REGISTER bits are initilialized to 1. But what about the WRITE SHIFT and the READ SHIFT registers? Are they affected somehow after a RESET has been applied?
2. Suppose the DRS is happily running and I have done some readouts in ROI mode, so that the only "1"-value bit in the READ SHIFT register is in a random position. If now I want to execute a FULL READOUT, should I use the procedure explained in the data sheet (figure 11) for the FULL READOUT mode? or is this procedure useless since my "1"-value bit is already set somewhere in the READ SHIFT register and therefore a ROI readout of 1024 cells would be the solution (and getting the initial position from the SROUT pin)?
Thanks a lot!
Have a nice day!
Giovanni |
Mon Apr 10 10:50:57 2017, Stefan Ritt, drs4 registers behaviour
|
Using the RESET line to reset registers is not a good idea since it can have some bad side-effects. The READ SHIFT register is NOT affected by RESET, so you have to inititialize these registers differently. To set a "1"-value at a defined position, you have to follow figure 11 in the data sheet. Once you executed that, your "1" is always at the same posiiton (namely cell #0), so after 1024 clock cycles you arrive at the same state, and do not have to re-do fig. 11 again.
Stefan
Giovanni Bruni wrote: |
Hej everyone!
I have some questions regarding what happens to some DRS registers in some scenarios:
1. How are the registers affected by a RESET? According to the data sheet all the CONFIG REGISTER bits are initilialized to 1. But what about the WRITE SHIFT and the READ SHIFT registers? Are they affected somehow after a RESET has been applied?
2. Suppose the DRS is happily running and I have done some readouts in ROI mode, so that the only "1"-value bit in the READ SHIFT register is in a random position. If now I want to execute a FULL READOUT, should I use the procedure explained in the data sheet (figure 11) for the FULL READOUT mode? or is this procedure useless since my "1"-value bit is already set somewhere in the READ SHIFT register and therefore a ROI readout of 1024 cells would be the solution (and getting the initial position from the SROUT pin)?
Thanks a lot!
Have a nice day!
Giovanni
|
|
Mon Apr 10 13:41:41 2017, Giovanni Bruni, drs4 registers behaviour
|
Hej Stefan! Thank you for your answer!
Just to be sure to have understood properly:
1. Using the RESET line should be avoided. And in any case, the CONFIG register and the WRITE SHIFT register need to be initialized "by hand" using the A0-A3, SRCLK and SRIN pins. Is it correct?
2. Doing the procedure shown in Figure 11 will always inject a "1" in cell #0 of the READ SHIFT register, regardless if (before starting the procedure) there was a "1" in any other cell, right?
Thank you!
Giovanni
Stefan Ritt wrote: |
Using the RESET line to reset registers is not a good idea since it can have some bad side-effects. The READ SHIFT register is NOT affected by RESET, so you have to inititialize these registers differently. To set a "1"-value at a defined position, you have to follow figure 11 in the data sheet. Once you executed that, your "1" is always at the same posiiton (namely cell #0), so after 1024 clock cycles you arrive at the same state, and do not have to re-do fig. 11 again.
Stefan
Giovanni Bruni wrote: |
Hej everyone!
I have some questions regarding what happens to some DRS registers in some scenarios:
1. How are the registers affected by a RESET? According to the data sheet all the CONFIG REGISTER bits are initilialized to 1. But what about the WRITE SHIFT and the READ SHIFT registers? Are they affected somehow after a RESET has been applied?
2. Suppose the DRS is happily running and I have done some readouts in ROI mode, so that the only "1"-value bit in the READ SHIFT register is in a random position. If now I want to execute a FULL READOUT, should I use the procedure explained in the data sheet (figure 11) for the FULL READOUT mode? or is this procedure useless since my "1"-value bit is already set somewhere in the READ SHIFT register and therefore a ROI readout of 1024 cells would be the solution (and getting the initial position from the SROUT pin)?
Thanks a lot!
Have a nice day!
Giovanni
|
|
|
Mon Apr 10 14:05:17 2017, Stefan Ritt, drs4 registers behaviour
|
1. WRITE SHIFT register and CONFIG registers are initialized to "1" on power up, but if you want to change that, use A0-A3 etc. as you indicated.
2. If you address the READ SHIFT register by applyin "1011" to A0-A3, the input of the register is connected to SRIN. So in fig. 11, you apply 1023x"0" plus 1x"1", which effectively clears the register and keeps one "1" at the last position, so on the next rising clock this gets shifted into position #0. If you do the readout, and NOT addresing the READ SHIFT register, then the input of that register is connected to it's output internally. Therefore the single "1" keep rotating on every 1024 clock cycles.
Giovanni Bruni wrote: |
Hej Stefan! Thank you for your answer!
Just to be sure to have understood properly:
1. Using the RESET line should be avoided. And in any case, the CONFIG register and the WRITE SHIFT register need to be initialized "by hand" using the A0-A3, SRCLK and SRIN pins. Is it correct?
2. Doing the procedure shown in Figure 11 will always inject a "1" in cell #0 of the READ SHIFT register, regardless if (before starting the procedure) there was a "1" in any other cell, right?
Thank you!
Giovanni
Stefan Ritt wrote: |
Using the RESET line to reset registers is not a good idea since it can have some bad side-effects. The READ SHIFT register is NOT affected by RESET, so you have to inititialize these registers differently. To set a "1"-value at a defined position, you have to follow figure 11 in the data sheet. Once you executed that, your "1" is always at the same posiiton (namely cell #0), so after 1024 clock cycles you arrive at the same state, and do not have to re-do fig. 11 again.
Stefan
Giovanni Bruni wrote: |
Hej everyone!
I have some questions regarding what happens to some DRS registers in some scenarios:
1. How are the registers affected by a RESET? According to the data sheet all the CONFIG REGISTER bits are initilialized to 1. But what about the WRITE SHIFT and the READ SHIFT registers? Are they affected somehow after a RESET has been applied?
2. Suppose the DRS is happily running and I have done some readouts in ROI mode, so that the only "1"-value bit in the READ SHIFT register is in a random position. If now I want to execute a FULL READOUT, should I use the procedure explained in the data sheet (figure 11) for the FULL READOUT mode? or is this procedure useless since my "1"-value bit is already set somewhere in the READ SHIFT register and therefore a ROI readout of 1024 cells would be the solution (and getting the initial position from the SROUT pin)?
Thanks a lot!
Have a nice day!
Giovanni
|
|
|
|
Tue Apr 11 09:07:33 2017, Giovanni Bruni, drs4 registers behaviour
|
Thank you Stefan for replying!
I have still the RESET issue in mind: how would you suggest to reset properly the DRS? Is there a particular procedure to follow instead of just sending a negative pulse to the RESET pin? Is it preferable to turn the DRS off and then restart?
Thanks!
Giovanni
Stefan Ritt wrote: |
1. WRITE SHIFT register and CONFIG registers are initialized to "1" on power up, but if you want to change that, use A0-A3 etc. as you indicated.
2. If you address the READ SHIFT register by applyin "1011" to A0-A3, the input of the register is connected to SRIN. So in fig. 11, you apply 1023x"0" plus 1x"1", which effectively clears the register and keeps one "1" at the last position, so on the next rising clock this gets shifted into position #0. If you do the readout, and NOT addresing the READ SHIFT register, then the input of that register is connected to it's output internally. Therefore the single "1" keep rotating on every 1024 clock cycles.
Giovanni Bruni wrote: |
Hej Stefan! Thank you for your answer!
Just to be sure to have understood properly:
1. Using the RESET line should be avoided. And in any case, the CONFIG register and the WRITE SHIFT register need to be initialized "by hand" using the A0-A3, SRCLK and SRIN pins. Is it correct?
2. Doing the procedure shown in Figure 11 will always inject a "1" in cell #0 of the READ SHIFT register, regardless if (before starting the procedure) there was a "1" in any other cell, right?
Thank you!
Giovanni
Stefan Ritt wrote: |
Using the RESET line to reset registers is not a good idea since it can have some bad side-effects. The READ SHIFT register is NOT affected by RESET, so you have to inititialize these registers differently. To set a "1"-value at a defined position, you have to follow figure 11 in the data sheet. Once you executed that, your "1" is always at the same posiiton (namely cell #0), so after 1024 clock cycles you arrive at the same state, and do not have to re-do fig. 11 again.
Stefan
Giovanni Bruni wrote: |
Hej everyone!
I have some questions regarding what happens to some DRS registers in some scenarios:
1. How are the registers affected by a RESET? According to the data sheet all the CONFIG REGISTER bits are initilialized to 1. But what about the WRITE SHIFT and the READ SHIFT registers? Are they affected somehow after a RESET has been applied?
2. Suppose the DRS is happily running and I have done some readouts in ROI mode, so that the only "1"-value bit in the READ SHIFT register is in a random position. If now I want to execute a FULL READOUT, should I use the procedure explained in the data sheet (figure 11) for the FULL READOUT mode? or is this procedure useless since my "1"-value bit is already set somewhere in the READ SHIFT register and therefore a ROI readout of 1024 cells would be the solution (and getting the initial position from the SROUT pin)?
Thanks a lot!
Have a nice day!
Giovanni
|
|
|
|
|
Tue Apr 11 09:41:44 2017, Stefan Ritt, drs4 registers behaviour
|
What I do is the following: Have the RESET input unconnected. When you power up, this makes an internal reset during the power up, and that's all you need. Then configure your registers using the sequences described in the manual. Then do not touch the RESET any more.
Stefan
Giovanni Bruni wrote: |
Thank you Stefan for replying!
I have still the RESET issue in mind: how would you suggest to reset properly the DRS? Is there a particular procedure to follow instead of just sending a negative pulse to the RESET pin? Is it preferable to turn the DRS off and then restart?
Thanks!
Giovanni
Stefan Ritt wrote: |
1. WRITE SHIFT register and CONFIG registers are initialized to "1" on power up, but if you want to change that, use A0-A3 etc. as you indicated.
2. If you address the READ SHIFT register by applyin "1011" to A0-A3, the input of the register is connected to SRIN. So in fig. 11, you apply 1023x"0" plus 1x"1", which effectively clears the register and keeps one "1" at the last position, so on the next rising clock this gets shifted into position #0. If you do the readout, and NOT addresing the READ SHIFT register, then the input of that register is connected to it's output internally. Therefore the single "1" keep rotating on every 1024 clock cycles.
Giovanni Bruni wrote: |
Hej Stefan! Thank you for your answer!
Just to be sure to have understood properly:
1. Using the RESET line should be avoided. And in any case, the CONFIG register and the WRITE SHIFT register need to be initialized "by hand" using the A0-A3, SRCLK and SRIN pins. Is it correct?
2. Doing the procedure shown in Figure 11 will always inject a "1" in cell #0 of the READ SHIFT register, regardless if (before starting the procedure) there was a "1" in any other cell, right?
Thank you!
Giovanni
Stefan Ritt wrote: |
Using the RESET line to reset registers is not a good idea since it can have some bad side-effects. The READ SHIFT register is NOT affected by RESET, so you have to inititialize these registers differently. To set a "1"-value at a defined position, you have to follow figure 11 in the data sheet. Once you executed that, your "1" is always at the same posiiton (namely cell #0), so after 1024 clock cycles you arrive at the same state, and do not have to re-do fig. 11 again.
Stefan
Giovanni Bruni wrote: |
Hej everyone!
I have some questions regarding what happens to some DRS registers in some scenarios:
1. How are the registers affected by a RESET? According to the data sheet all the CONFIG REGISTER bits are initilialized to 1. But what about the WRITE SHIFT and the READ SHIFT registers? Are they affected somehow after a RESET has been applied?
2. Suppose the DRS is happily running and I have done some readouts in ROI mode, so that the only "1"-value bit in the READ SHIFT register is in a random position. If now I want to execute a FULL READOUT, should I use the procedure explained in the data sheet (figure 11) for the FULL READOUT mode? or is this procedure useless since my "1"-value bit is already set somewhere in the READ SHIFT register and therefore a ROI readout of 1024 cells would be the solution (and getting the initial position from the SROUT pin)?
Thanks a lot!
Have a nice day!
Giovanni
|
|
|
|
|
|
Wed Apr 5 12:40:16 2017, Martin Petriska, DRS4 eval board v4 coincidence firmware changes for triger for short pulses
|
I would like to implement fpga firmware changes for DRS4 eval board v4 to put there posibility for standard coincidence (for example to get triger on two short (5ns pulses from Plastic scintilator) in 100ns coincidence window), Similar but more complex was done for eval v.5 boards ( https://forge.physik.rwth-aachen.de/projects/drs4-rwth ) Im beginner in state of FPGA design, but hope it will be not so dificult to implement same functionality in eval4 board. Is there any SVN server with firmware sources for evaluation board? Im litle bit confused with different firmware sources in linux and windows installation packages, For example whose are last eval4 board firmware souces ? (There are some eval4 sources in 5.0.6 files, but not sure if its workable)
May be didnt make same changes already? |
Mon Apr 10 10:48:03 2017, Stefan Ritt, DRS4 eval board v4 coincidence firmware changes for triger for short pulses
|
You have to download the package for your board, which then includes also the correct firmware for your board. If you have a V4 board, your firmware is in drs-4.0.2.tar.gz which you can download from Dropbox at https://www.dropbox.com/sh/clqo7ekr0ysbrip/AACoWJzrQAbf3WiBJHG89bGGa?dl=0
Martin Petriska wrote: |
I would like to implement fpga firmware changes for DRS4 eval board v4 to put there posibility for standard coincidence (for example to get triger on two short (5ns pulses from Plastic scintilator) in 100ns coincidence window), Similar but more complex was done for eval v.5 boards ( https://forge.physik.rwth-aachen.de/projects/drs4-rwth ) Im beginner in state of FPGA design, but hope it will be not so dificult to implement same functionality in eval4 board. Is there any SVN server with firmware sources for evaluation board? Im litle bit confused with different firmware sources in linux and windows installation packages, For example whose are last eval4 board firmware souces ? (There are some eval4 sources in 5.0.6 files, but not sure if its workable)
May be didnt make same changes already?
|
|
Fri Feb 24 17:34:28 2017, Tarik Zengin, Passing parameters to drscl
|
Hi everyone,
I wonder if there is a way to pass parameters to drscl. What I specifically want to do is calling drscl from a shell script and read/save some data. I want to schedule a measurement. Therefore I need to call drscl from the command line using some parameters.
It would look something like this;
#!/bin/bash
for i in {0..100}
do
echo "Reading $i"
./drscl read 0 0 test.xml
sleep 1
done
This doesn't work of course. drscl won't take arguments from the command line. Can you suggest a way to do this please?
Thank you. |
Fri Feb 24 18:35:38 2017, Stefan Ritt, Passing parameters to drscl
|
This is indeed currently not implemented. But there is a simple C program drs_exam.cpp, which connects to a board and safes some data. You could modify that program to your needs.
Stefan
Tarik Zengin wrote: |
Hi everyone,
I wonder if there is a way to pass parameters to drscl. What I specifically want to do is calling drscl from a shell script and read/save some data. I want to schedule a measurement. Therefore I need to call drscl from the command line using some parameters.
It would look something like this;
#!/bin/bash
for i in {0..100}
do
echo "Reading $i"
./drscl read 0 0 test.xml
sleep 1
done
This doesn't work of course. drscl won't take arguments from the command line. Can you suggest a way to do this please?
Thank you.
|
|
Tue Jan 31 01:37:35 2017, VO HONG HAI, LLD and ULD discriminations,
|
Dear Stefan,
Is there any way to develop LLD and ULD discrimination in DSR-4 evaluation board?
Best regards,
V.H.Hai |
Tue Jan 31 08:40:04 2017, Stefan Ritt, LLD and ULD discriminations,
|
Not inside the board. Each channel has a single discriminator. You can select to trigger on a rising or falling edge, but you don't have two levels. What you can do however is to make an external trigger, like using old NIM logic. You can make discrimaiton with different levels and use a coincidence unit to combine them. Then feed the trigger into the external trigger input of the evaluation board (5V TTL level, not NIM level!).
Stefan
VO HONG HAI wrote: |
Dear Stefan, Is there any way to develop LLD and ULD discrimination in DSR-4 evaluation board? Best regards, V.H.Hai |
|
Sat Jan 28 14:11:58 2017, Danny Petschke, AND trigger problems
|
Dear Stefan,
I have 2 identical pulses as a splittet signal with an amplitude of 300mV. Range is -0.5-0.5V, 5.12GSamp using the Evaluation-Board. Both signals are triggered in AND logic. One of the signals is delayed by a fixed value of 1-50ns for testing. On increasing the trigger Level from 10% to 50% of amplitude (pulse rise time is 2.5ns) pulses cannot anymore triggered above 4-5ns delay. It means there is a proportionality between the trigger level and the available range where 2 signals can be triggered in AND logic (Time-difference between 2 pulses). Do I anything misunderstand or is the time the comparator needs by higher trigger Levels for comparation longer than the 200ns at 5.12GSamp?
Board was timing and voltage calibrated before.
Thx
Danny |
Mon Jan 30 16:37:33 2017, Stefan Ritt, AND trigger problems
|
In the evaluation board we use an ADCMP601 comparator, which has a setup and hold time of 4.6 ns. So a pulse which exceeds the threshold for less than 4.6 ns will not trigger the board. If you AND two signals together, an additional constraint might apply on the coincidence pulse. This is processed in the FPGA, but once it becomes too short, it won't trigger the board as well. I never made a real measurement of that, but I would not be suprised if the coicidence signal (output of AND), needs to be at least 4-5 ns wide.
If you need more refined trigger conditions, make yourself an old-fashioned external trigger (with NIM modules for example), stretch the output to 10 ns and feed it into the external trigger input of the DRS4 board (5V CMOS logic, not NIM!).
Best,
Stefan
Danny Petschke wrote: |
Dear Stefan,
I have 2 identical pulses as a splittet signal with an amplitude of 300mV. Range is -0.5-0.5V, 5.12GSamp using the Evaluation-Board. Both signals are triggered in AND logic. One of the signals is delayed by a fixed value of 1-50ns for testing. On increasing the trigger Level from 10% to 50% of amplitude (pulse rise time is 2.5ns) pulses cannot anymore triggered above 4-5ns delay. It means there is a proportionality between the trigger level and the available range where 2 signals can be triggered in AND logic (Time-difference between 2 pulses). Do I anything misunderstand or is the time the comparator needs by higher trigger Levels for comparation longer than the 200ns at 5.12GSamp?
Board was timing and voltage calibrated before.
Thx
Danny
|
|
Fri Jan 13 12:58:22 2017, Gregor Kramberger, DRS software doesn't work under Windows XP SP3
|
Hi all
I have a problem with running the DRSOSC under windows XP SP3. We have some hardware which is not supported under newer versions of windows and we would like to use DRS boards along it, therefore we would higly appreciated any help in that direction. We have installed the software (V 5.03) to two different XP machines and got the same problem. The driver installs without any problem, but when the drsosc is run the system says " drsosc.exe is not a valid Win32 application". We have developed our own API for our software which also doesn't recognize the board. It says on the www page that it has been tested for windows XP, but I would appreciate if you can verify it? With best regards and thanks... |
Fri Jan 13 13:16:09 2017, Stefan Ritt, DRS software doesn't work under Windows XP SP3
|
The error probably comes from the fact that the drsosc.exe application is a 64-bit application and cannot be executed under XP any more. Unfortunately XP is forbidden at our institute for security reasons, so I have no machine around where I could compile the executable fro XP. Another problem is the libusb library used by drsosc.exe. Not sure if there is a XP version available any more. Have a look yourself at http://www.libusb.org/wiki/windows_backend
I only see two possibilities for you: 1) Try to compile the program under Windows XP yourself, either with MS Visual Studio or with MinGW (http://www.mingw.org/). 2) Set up a virtual machine on your PC (for example with Virtualbox), and install either a newer version of Windows or a Linux distribution. The Linux excutable can then be compiled directly from sources as written in the documentation.
Stefan
Gregor Kramberger wrote: |
Hi all
I have a problem with running the DRSOSC under windows XP SP3. We have some hardware which is not supported under newer versions of windows and we would like to use DRS boards along it, therefore we would higly appreciated any help in that direction. We have installed the software (V 5.03) to two different XP machines and got the same problem. The driver installs without any problem, but when the drsosc is run the system says " drsosc.exe is not a valid Win32 application". We have developed our own API for our software which also doesn't recognize the board. It says on the www page that it has been tested for windows XP, but I would appreciate if you can verify it? With best regards and thanks...
|
|
Fri Jan 13 13:50:10 2017, Stefan Ritt, DRS software doesn't work under Windows XP SP3
|
Can you try that executable under XP: https://www.dropbox.com/s/j1n09afhbmh0zzu/drsosc.exe?dl=0
Gregor Kramberger wrote: |
Hi all
I have a problem with running the DRSOSC under windows XP SP3. We have some hardware which is not supported under newer versions of windows and we would like to use DRS boards along it, therefore we would higly appreciated any help in that direction. We have installed the software (V 5.03) to two different XP machines and got the same problem. The driver installs without any problem, but when the drsosc is run the system says " drsosc.exe is not a valid Win32 application". We have developed our own API for our software which also doesn't recognize the board. It says on the www page that it has been tested for windows XP, but I would appreciate if you can verify it? With best regards and thanks...
|
|
Wed Nov 23 08:17:23 2016, Abhishek Rajput, Potential Incorrect Timing Calibration for DRS4 Data
|
Hello,
I was running through a particular binary file containing data taken on all 4 channels of the DRS4 and printing out the value of the first time sample for each channel (per event). While doing so, I noticed that some of these times were negative. For this dataset, channel 1 was chosen as the reference channel (which is the default setup in Stefan's DRS4 macro). From my understanding, the calibration procedure delineated in the DRS4 manual and shown in the code below is supposed to sync the timing of each channel relative to sample 0. However, this does not appear to be the case for when I print out the time value of the first sample, I notice that only channel 1's 0th sample is set to 0. The first sample for the other channels is nonzero (and most often negative).
Even more strange is when I test another 4-channel dataset with the same code, this issue does not appear. More specifically, the first time sample on each waveform on all channels is set to 0, as should be the case.
My question is therefore whether or not the timing calibration varies from dataset to dataset. My initial thought was that this should not be the case, but I have two different data sets taken on the same set of channels which give different timing calibration results. Are there any circumstances under which this behavior can happen?
for (ch=0 ; ch<5 ; ch++) {
i = fread(hdr, sizeof(hdr), 1, f);
if (i < 1)
break;
if (hdr[0] != 'C') {
// event header found
fseek(f, -4, SEEK_CUR);
break;
}
chn_index = hdr[3] - '0' - 1;
fread(voltage, sizeof(short), 1024, f);
for (i=0 ; i<1024 ; i++) {
// convert data to volts
waveform[chn_index][i] = (voltage[i] / 65536. - 0.5);
// calculate time for this cell
for (j=0,time[chn_index][i]=0 ; j<i ; j++)
time[chn_index][i] += bin_width[chn_index][(j+eh.trigger_cell) % 1024];
}
}
// align cell #0 of all channels
t1 = time[0][(1024-eh.trigger_cell) % 1024];
for (ch=1 ; ch<4 ; ch++) {
t2 = time[ch][(1024-eh.trigger_cell) % 1024];
dt = t1 - t2;
for (i=0 ; i<1024 ; i++)
time[ch][i] += dt;
} |
Thu Nov 24 13:24:26 2016, Stefan Ritt, Potential Incorrect Timing Calibration for DRS4 Data
|
The code in the macro is correct. The misconception lies in the definition what "sample 0" means. Please view the attached picture. This is simplified case with a DRS chip with only 8 cells (instead of 1024). There are two events (blue and red). In the first event, the chip is stopped at trigger cell (tc) 2, in the second case at 5. Since the readout starts with the trigger cell, the first readout sample in the first event belongs to cell #2, the next one to cell #3 and so on. In the second (red) case, the first sample belongs to cell #5, the second to cell #6 and so on. "Aligning cells 0" now means that the physical cell 0 (not the readout sample) is aligned for each channel. In the first event, the 7th readout sample will have the same time in all channels, in the second event the fourth readout cells will have the same time. This is because physical cell #0 is always at different places inside the readout array.
Stefan
Abhishek Rajput wrote: |
Hello,
I was running through a particular binary file containing data taken on all 4 channels of the DRS4 and printing out the value of the first time sample for each channel (per event). While doing so, I noticed that some of these times were negative. For this dataset, channel 1 was chosen as the reference channel (which is the default setup in Stefan's DRS4 macro). From my understanding, the calibration procedure delineated in the DRS4 manual and shown in the code below is supposed to sync the timing of each channel relative to sample 0. However, this does not appear to be the case for when I print out the time value of the first sample, I notice that only channel 1's 0th sample is set to 0. The first sample for the other channels is nonzero (and most often negative).
Even more strange is when I test another 4-channel dataset with the same code, this issue does not appear. More specifically, the first time sample on each waveform on all channels is set to 0, as should be the case.
My question is therefore whether or not the timing calibration varies from dataset to dataset. My initial thought was that this should not be the case, but I have two different data sets taken on the same set of channels which give different timing calibration results. Are there any circumstances under which this behavior can happen?
for (ch=0 ; ch<5 ; ch++) {
i = fread(hdr, sizeof(hdr), 1, f);
if (i < 1)
break;
if (hdr[0] != 'C') {
// event header found
fseek(f, -4, SEEK_CUR);
break;
}
chn_index = hdr[3] - '0' - 1;
fread(voltage, sizeof(short), 1024, f);
for (i=0 ; i<1024 ; i++) {
// convert data to volts
waveform[chn_index][i] = (voltage[i] / 65536. - 0.5);
// calculate time for this cell
for (j=0,time[chn_index][i]=0 ; j<i ; j++)
time[chn_index][i] += bin_width[chn_index][(j+eh.trigger_cell) % 1024];
}
}
// align cell #0 of all channels
t1 = time[0][(1024-eh.trigger_cell) % 1024];
for (ch=1 ; ch<4 ; ch++) {
t2 = time[ch][(1024-eh.trigger_cell) % 1024];
dt = t1 - t2;
for (i=0 ; i<1024 ; i++)
time[ch][i] += dt;
}
|
|
Tue Nov 29 23:19:06 2016, Abhishek Rajput, Potential Incorrect Timing Calibration for DRS4 Data
|
Hello Stefan,
Thank you for the excellent explanation and diagram. This part of the code is now much clearer to me.
My other questions pertain to the "trigger cell". Firstly, what precisely does this mean? Moreover, how does the "trigger cell" relate to the trigger time delay we can set in the DRS4 application? This is causing some confusion for me, because regardless of where you set the trigger time delay on the DRS4 application, there are still points on the waveform that are saved prior to the moment in time when a pulse exceeds some voltage threshold we set in the application. I get the impression that "trigger delay" and "trigger cell" are unrelated concepts, so any clarification you can provide would be greatly appreciated.
Abhishek
Stefan Ritt wrote: |
The code in the macro is correct. The misconception lies in the definition what "sample 0" means. Please view the attached picture. This is simplified case with a DRS chip with only 8 cells (instead of 1024). There are two events (blue and red). In the first event, the chip is stopped at trigger cell (tc) 2, in the second case at 5. Since the readout starts with the trigger cell, the first readout sample in the first event belongs to cell #2, the next one to cell #3 and so on. In the second (red) case, the first sample belongs to cell #5, the second to cell #6 and so on. "Aligning cells 0" now means that the physical cell 0 (not the readout sample) is aligned for each channel. In the first event, the 7th readout sample will have the same time in all channels, in the second event the fourth readout cells will have the same time. This is because physical cell #0 is always at different places inside the readout array.
Stefan
Abhishek Rajput wrote: |
Hello,
I was running through a particular binary file containing data taken on all 4 channels of the DRS4 and printing out the value of the first time sample for each channel (per event). While doing so, I noticed that some of these times were negative. For this dataset, channel 1 was chosen as the reference channel (which is the default setup in Stefan's DRS4 macro). From my understanding, the calibration procedure delineated in the DRS4 manual and shown in the code below is supposed to sync the timing of each channel relative to sample 0. However, this does not appear to be the case for when I print out the time value of the first sample, I notice that only channel 1's 0th sample is set to 0. The first sample for the other channels is nonzero (and most often negative).
Even more strange is when I test another 4-channel dataset with the same code, this issue does not appear. More specifically, the first time sample on each waveform on all channels is set to 0, as should be the case.
My question is therefore whether or not the timing calibration varies from dataset to dataset. My initial thought was that this should not be the case, but I have two different data sets taken on the same set of channels which give different timing calibration results. Are there any circumstances under which this behavior can happen?
for (ch=0 ; ch<5 ; ch++) {
i = fread(hdr, sizeof(hdr), 1, f);
if (i < 1)
break;
if (hdr[0] != 'C') {
// event header found
fseek(f, -4, SEEK_CUR);
break;
}
chn_index = hdr[3] - '0' - 1;
fread(voltage, sizeof(short), 1024, f);
for (i=0 ; i<1024 ; i++) {
// convert data to volts
waveform[chn_index][i] = (voltage[i] / 65536. - 0.5);
// calculate time for this cell
for (j=0,time[chn_index][i]=0 ; j<i ; j++)
time[chn_index][i] += bin_width[chn_index][(j+eh.trigger_cell) % 1024];
}
}
// align cell #0 of all channels
t1 = time[0][(1024-eh.trigger_cell) % 1024];
for (ch=1 ; ch<4 ; ch++) {
t2 = time[ch][(1024-eh.trigger_cell) % 1024];
dt = t1 - t2;
for (i=0 ; i<1024 ; i++)
time[ch][i] += dt;
}
|
|
|
Wed Nov 30 08:53:58 2016, Stefan Ritt, Potential Incorrect Timing Calibration for DRS4 Data
|
The inverter chain in the DRS4 is continously running in a ring. Once you get a trigger, it is stopped. This happens in any of the 1024 cells. The last cell which sampled a signal plus ne is called "trigger cell". In the previous diagram in event #1, the last cell sampling was "1", so the trigger cell is "2". In event 2 (red case), the trigger cell is 5. If you would run like this, you see only the part of the waveform BEFORE your trigger (since the DRS4 is continously sampling and is stopped with the trigger). In order to see the full peak of your waveform, you can apply some external trigger to shift the trigger position to the right. This is done in the FPGA reading out the DRS4 chip. If your peak is let's say 20 ns wide, and you delay your trigger by 30 ns, you see the peak plus 10 ns right of the peak.
Stefan
Abhishek Rajput wrote: |
Hello Stefan,
Thank you for the excellent explanation and diagram. This part of the code is now much clearer to me.
My other questions pertain to the "trigger cell". Firstly, what precisely does this mean? Moreover, how does the "trigger cell" relate to the trigger time delay we can set in the DRS4 application? This is causing some confusion for me, because regardless of where you set the trigger time delay on the DRS4 application, there are still points on the waveform that are saved prior to the moment in time when a pulse exceeds some voltage threshold we set in the application. I get the impression that "trigger delay" and "trigger cell" are unrelated concepts, so any clarification you can provide would be greatly appreciated.
Abhishek
|
|
Fri Dec 9 04:17:46 2016, Abhishek Rajput, Potential Incorrect Timing Calibration for DRS4 Data
|
Hello Stefan,
Many thanks for the explanations. You've cleared my confusion in this matter.
Abhishek Rajput
Stefan Ritt wrote: |
The inverter chain in the DRS4 is continously running in a ring. Once you get a trigger, it is stopped. This happens in any of the 1024 cells. The last cell which sampled a signal plus ne is called "trigger cell". In the previous diagram in event #1, the last cell sampling was "1", so the trigger cell is "2". In event 2 (red case), the trigger cell is 5. If you would run like this, you see only the part of the waveform BEFORE your trigger (since the DRS4 is continously sampling and is stopped with the trigger). In order to see the full peak of your waveform, you can apply some external trigger to shift the trigger position to the right. This is done in the FPGA reading out the DRS4 chip. If your peak is let's say 20 ns wide, and you delay your trigger by 30 ns, you see the peak plus 10 ns right of the peak.
Stefan
Abhishek Rajput wrote: |
Hello Stefan,
Thank you for the excellent explanation and diagram. This part of the code is now much clearer to me.
My other questions pertain to the "trigger cell". Firstly, what precisely does this mean? Moreover, how does the "trigger cell" relate to the trigger time delay we can set in the DRS4 application? This is causing some confusion for me, because regardless of where you set the trigger time delay on the DRS4 application, there are still points on the waveform that are saved prior to the moment in time when a pulse exceeds some voltage threshold we set in the application. I get the impression that "trigger delay" and "trigger cell" are unrelated concepts, so any clarification you can provide would be greatly appreciated.
Abhishek
|
|
|
Wed Nov 30 17:48:39 2016, samridha kunwar, DRS4 Initiation
|
I am having a general problem getting read back using the ROI mode. In the transparent mode everything looks good. These are the steps that I take:
1) configure register (b"11111111",addr = "1100")
2) configure write shift register (b"11111111", addr = "1101")
3) assert DENABLE and DWRITE
4) wait for trigger
5) on trigger deassert DWRITE
6) Strobe RSRLOAD
7)Set drs4 address to enable all channels (address = "1001")
8)give n SRCLK pulses
9) goto 3 and repeat.
Am I missing something? Everything looks straight forward based on the manual yet in the readout mode I only get noise. I do get the stop position on SROUT and the refclk is at 475 KHz as desired and I get the desired behaviour for DTAP toggling at the same frequency as refclk. |
Wed Nov 30 19:05:24 2016, Stefan Ritt, DRS4 Initiation
|
Uhh, there are 1000 things which might be wrong. A bit like "my car is not working, it makes strange noise". Without having a look under the hood, there is just some wild guessing:
- Is your ROFS input at the right value? Your O-OFS?
- All VDD voltages there? Input voltage outside the rails?
- Your RSLOAD pulse long enough (>10ns)
- What happens if you put a really big sinal at the input, like 100 MHz sine wave with 2V p-p
The easiest is to have a look at the evaluation board and copy your new board like 1:1, also copy the VHDL readout code. Much easier that to start from scratch.
Stefan
samridha kunwar wrote: |
I am having a general problem getting read back using the ROI mode. In the transparent mode everything looks good. These are the steps that I take:
1) configure register (b"11111111",addr = "1100")
2) configure write shift register (b"11111111", addr = "1101")
3) assert DENABLE and DWRITE
4) wait for trigger
5) on trigger deassert DWRITE
6) Strobe RSRLOAD
7)Set drs4 address to enable all channels (address = "1001")
8)give n SRCLK pulses
9) goto 3 and repeat.
Am I missing something? Everything looks straight forward based on the manual yet in the readout mode I only get noise. I do get the stop position on SROUT and the refclk is at 475 KHz as desired and I get the desired behaviour for DTAP toggling at the same frequency as refclk.
|
|
Fri Dec 2 15:32:52 2016, samridha kunwar, DRS4 Initiation
|
Thanks for replying Stefan.
I was more so just concerned with the steps in the firmware when I had asked. However, yes the ROFS (1.05V) and O-OFS (0.9 V was 1.3 V earlier but, changed this becasue of ADC input requirements) are per spec, the VDD voltages are all there and input voltages are within the rails and finally the RSLOAD (16 ns) too is ok. Looking at your eval board firmware , on appearance it looks exactly like what I am doing. I thought maybe I was/ still am missing some intermediate addressing stage. What I wrote earlier is what I still have.
Stefan Ritt wrote: |
Uhh, there are 1000 things which might be wrong. A bit like "my car is not working, it makes strange noise". Without having a look under the hood, there is just some wild guessing:
- Is your ROFS input at the right value? Your O-OFS?
- All VDD voltages there? Input voltage outside the rails?
- Your RSLOAD pulse long enough (>10ns)
- What happens if you put a really big sinal at the input, like 100 MHz sine wave with 2V p-p
The easiest is to have a look at the evaluation board and copy your new board like 1:1, also copy the VHDL readout code. Much easier that to start from scratch.
Stefan
samridha kunwar wrote: |
I am having a general problem getting read back using the ROI mode. In the transparent mode everything looks good. These are the steps that I take:
1) configure register (b"11111111",addr = "1100")
2) configure write shift register (b"11111111", addr = "1101")
3) assert DENABLE and DWRITE
4) wait for trigger
5) on trigger deassert DWRITE
6) Strobe RSRLOAD
7)Set drs4 address to enable all channels (address = "1001")
8)give n SRCLK pulses
9) goto 3 and repeat.
Am I missing something? Everything looks straight forward based on the manual yet in the readout mode I only get noise. I do get the stop position on SROUT and the refclk is at 475 KHz as desired and I get the desired behaviour for DTAP toggling at the same frequency as refclk.
|
|
|
Fri Dec 2 16:47:37 2016, Stefan Ritt, DRS4 Initiation
|
No, I can't think of anything else. There is no intermediate addressing stage. The only thing which sometimes happens is that the QFN76 package is not soldered correctly. If you don't have this under control, some pins might have a bad contact. You can check this by touching with a oscilloscope probe not the PCB pads but really the pins from the side, which is a bit tricky.
Stefan
samridha kunwar wrote: |
Thanks for replying Stefan.
I was more so just concerned with the steps in the firmware when I had asked. However, yes the ROFS (1.05V) and O-OFS (0.9 V was 1.3 V earlier but, changed this becasue of ADC input requirements) are per spec, the VDD voltages are all there and input voltages are within the rails and finally the RSLOAD (16 ns) too is ok. Looking at your eval board firmware , on appearance it looks exactly like what I am doing. I thought maybe I was/ still am missing some intermediate addressing stage. What I wrote earlier is what I still have.
Stefan Ritt wrote: |
Uhh, there are 1000 things which might be wrong. A bit like "my car is not working, it makes strange noise". Without having a look under the hood, there is just some wild guessing:
- Is your ROFS input at the right value? Your O-OFS?
- All VDD voltages there? Input voltage outside the rails?
- Your RSLOAD pulse long enough (>10ns)
- What happens if you put a really big sinal at the input, like 100 MHz sine wave with 2V p-p
The easiest is to have a look at the evaluation board and copy your new board like 1:1, also copy the VHDL readout code. Much easier that to start from scratch.
Stefan
samridha kunwar wrote: |
I am having a general problem getting read back using the ROI mode. In the transparent mode everything looks good. These are the steps that I take:
1) configure register (b"11111111",addr = "1100")
2) configure write shift register (b"11111111", addr = "1101")
3) assert DENABLE and DWRITE
4) wait for trigger
5) on trigger deassert DWRITE
6) Strobe RSRLOAD
7)Set drs4 address to enable all channels (address = "1001")
8)give n SRCLK pulses
9) goto 3 and repeat.
Am I missing something? Everything looks straight forward based on the manual yet in the readout mode I only get noise. I do get the stop position on SROUT and the refclk is at 475 KHz as desired and I get the desired behaviour for DTAP toggling at the same frequency as refclk.
|
|
|
|
Mon Nov 28 22:28:34 2016, Randall Gladen, Long timing between two channels
|
I don't believe I fully understand how the timing works between multiple channels on DRS4 board, even after reading the manual, but I am hoping to measure a time difference between two channels longer than 1024/sampling rate. So far, I have written a program in Matlab to extract timing and voltage information from the binary file to find the time difference between two channels that are set with the AND trigger logic and appear within approximately 80 ns of each other at a sampling rate of 1 GSPS. This works as intended, but I would now like to try to measure time differences of anywhere between 50 ns and several ms within a single spectrum. Since this is out of the range of only 1024 channels above 1GSPS, is it possible for the board to keep track of the time between two trigger pulses that occur at time differences longer than 1024/sampling rate?
Thank you very much for your help, and if I am severely misunderstanding how the board works, please forgive my ignorance and feel free to correct me,
~Randall
Edit: I forgot to mention that I am collecting the data using the provided DRS4 Oscilloscope software. |
Wed Nov 30 10:45:29 2016, Stefan Ritt, Long timing between two channels
|
You cannot measure times longer than 1024/sampling rate.
Stefan
Randall Gladen wrote: |
I don't believe I fully understand how the timing works between multiple channels on DRS4 board, even after reading the manual, but I am hoping to measure a time difference between two channels longer than 1024/sampling rate. So far, I have written a program in Matlab to extract timing and voltage information from the binary file to find the time difference between two channels that are set with the AND trigger logic and appear within approximately 80 ns of each other at a sampling rate of 1 GSPS. This works as intended, but I would now like to try to measure time differences of anywhere between 50 ns and several ms within a single spectrum. Since this is out of the range of only 1024 channels above 1GSPS, is it possible for the board to keep track of the time between two trigger pulses that occur at time differences longer than 1024/sampling rate?
Thank you very much for your help, and if I am severely misunderstanding how the board works, please forgive my ignorance and feel free to correct me,
~Randall
Edit: I forgot to mention that I am collecting the data using the provided DRS4 Oscilloscope software.
|
|
Thu Nov 24 00:40:38 2016, Alexey Lubinets, PLL did not lock
|
Hello, everybody!
I installed DRSosc and DRScl. Command line works normally (at least, it can "see" the board). But when I start the oscilloscope, I have an error: "PLLs did not lock on USB board #0, serial number #...". In Info section I can see the board type = 9 (and in the error message I have "USB board #0").
After that I have a warning: "Board on USB0 has invalid voltge calibration. Only raw data will be displayed". I tried to execute voltage calibration using DRSosc and DRScl, but it did not help.
Did anybody face such broblems? Does anybody know, how to fix them?
Thank you. Alexey. |
Thu Nov 24 08:13:23 2016, Stefan Ritt, PLL did not lock
|
Which serial number has the board? Has it been in use before or is it a new board?
Stefan
Alexey Lubinets wrote: |
Hello, everybody!
I installed DRSosc and DRScl. Command line works normally (at least, it can "see" the board). But when I start the oscilloscope, I have an error: "PLLs did not lock on USB board #0, serial number #...". In Info section I can see the board type = 9 (and in the error message I have "USB board #0").
After that I have a warning: "Board on USB0 has invalid voltge calibration. Only raw data will be displayed". I tried to execute voltage calibration using DRSosc and DRScl, but it did not help.
Did anybody face such broblems? Does anybody know, how to fix them?
Thank you. Alexey.
|
|
Mon Nov 28 16:48:15 2016, Alexey Lubinets, PLL did not lock
|
The serial number is 2586. This board is about two years old, and it might be in use (but I do not know exactly).
Stefan Ritt wrote: |
Which serial number has the board? Has it been in use before or is it a new board?
Stefan
Alexey Lubinets wrote: |
Hello, everybody!
I installed DRSosc and DRScl. Command line works normally (at least, it can "see" the board). But when I start the oscilloscope, I have an error: "PLLs did not lock on USB board #0, serial number #...". In Info section I can see the board type = 9 (and in the error message I have "USB board #0").
After that I have a warning: "Board on USB0 has invalid voltge calibration. Only raw data will be displayed". I tried to execute voltage calibration using DRSosc and DRScl, but it did not help.
Did anybody face such broblems? Does anybody know, how to fix them?
Thank you. Alexey.
|
|
|
Mon Nov 28 16:52:38 2016, Stefan Ritt, PLL did not lock
|
Have you tried to unplug and re-plug the board a few times? According to our database, you should have three boards. Do all three show the same behavior or only this board? In case all three show this, it could be a hint of a software problem. If two boards are good and one is bad, this would be a hint of a hardware problem (broken board).
Stefan
Alexey Lubinets wrote: |
The serial number is 2586. This board is about two years old, and it might be in use (but I do not know exactly).
Stefan Ritt wrote: |
Which serial number has the board? Has it been in use before or is it a new board?
Stefan
Alexey Lubinets wrote: |
Hello, everybody!
I installed DRSosc and DRScl. Command line works normally (at least, it can "see" the board). But when I start the oscilloscope, I have an error: "PLLs did not lock on USB board #0, serial number #...". In Info section I can see the board type = 9 (and in the error message I have "USB board #0").
After that I have a warning: "Board on USB0 has invalid voltge calibration. Only raw data will be displayed". I tried to execute voltage calibration using DRSosc and DRScl, but it did not help.
Did anybody face such broblems? Does anybody know, how to fix them?
Thank you. Alexey.
|
|
|
|
Fri Nov 18 05:52:45 2016, Kurtis Nishimura, Channel offsets in GetTime()
|
Hello,
I have a question about the GetTime() method in DRS.cpp. I understand how the DT values are applied for all channels, and I also understand from the evaluation board manual that the timing of each channel is synchronized at sample 0, so samples should really be aligned from channel-to-channel relative to sample 0.
However, DRS.cpp has the following snippet in DrsBoard::GetTime():
if (channelIndex > 0) {
// correct all channels to channel 0 (Daniel's method)
iend = tc >= 700 ? 700+1024 : 700;
for (i=tc,gt0=0 ; i<iend ; i++)
gt0 += fCellDT[chipIndex][0][i % 1024];
for (i=tc,gt=0 ; i<iend ; i++)
gt += fCellDT[chipIndex][channelIndex][i % 1024];
for (i=0 ; i<fChannelDepth ; i++)
time[i] += (float)(gt0 - gt);
}
I can see what this is calculating and applying such an offset, but I don't understand why things seem to be referenced to sample 700. Is there a particular reason why sample 700 is chosen here? This does not seem like a straightforward application of the attached instructions from the evaluation board user's manual.
Any insight would be much appreciated!
Thanks so much,
-Kurtis |
Mon Nov 21 14:13:32 2016, Stefan Ritt, Channel offsets in GetTime()
|
Cell 700 is arbitrary. You can choose any cell to align the channels to each other. The only requirement is that it's always the same cell for each event. Historically, Daniel chose cell #700 more or less arbitrary, but later we found out that this works with any cell. So for the publication we went with cell #0 (and that's why we have t_ch,0 in the paper), but cell #700 was left in the code because of lazyness. Feel free to replace 700 with any other number and you should get the same result. In a newer version of the software I use
// align cell#0 of all channels
float t1 = time[0][(1024-tc) % 1024];
for (int ch=1 ; ch<8 ; ch++) {
float t2 = time[ch][(1024-tc) % 1024];
float dt = t1 - t2;
for (int i=0 ; i<1024 ; i++)
time[ch][i] += dt;
}
which is also a bit simpler. So time[ch] contains already the integrated time array (like 0.2 ns, 0.4 ns, 0.6 ns if at 5 GSPS, not the delta_t values as in the DRS.cpp code). Since the readout starts with cell # tc, the cell time[channel][1024-tc] is the physical cell #0 of the chip. The code makes sure that cell #0 in all 8 channels has the same time value.
Best regards,
Stefan
Kurtis Nishimura wrote: |
Hello,
I have a question about the GetTime() method in DRS.cpp. I understand how the DT values are applied for all channels, and I also understand from the evaluation board manual that the timing of each channel is synchronized at sample 0, so samples should really be aligned from channel-to-channel relative to sample 0.
However, DRS.cpp has the following snippet in DrsBoard::GetTime():
if (channelIndex > 0) {
// correct all channels to channel 0 (Daniel's method)
iend = tc >= 700 ? 700+1024 : 700;
for (i=tc,gt0=0 ; i<iend ; i++)
gt0 += fCellDT[chipIndex][0][i % 1024];
for (i=tc,gt=0 ; i<iend ; i++)
gt += fCellDT[chipIndex][channelIndex][i % 1024];
for (i=0 ; i<fChannelDepth ; i++)
time[i] += (float)(gt0 - gt);
}
I can see what this is calculating and applying such an offset, but I don't understand why things seem to be referenced to sample 700. Is there a particular reason why sample 700 is chosen here? This does not seem like a straightforward application of the attached instructions from the evaluation board user's manual.
Any insight would be much appreciated!
Thanks so much,
-Kurtis
|
|
Wed Mar 9 09:57:20 2016, Christian D, LabView
|
Hi,
I would like to use the DRS4 board with LabView for fast readout.
Do you know anyone who has written a VI for that?
Thanks,
Christian |
Fri Nov 18 16:38:42 2016, Gerard Montarou, LabView
|
Hello,
Did you start to write some VI to interface DRS4board with labview ?
i also have in mind to do that.I am surprised that nobody alraedy did it since there is no answer toyour question
gerard
Christian D wrote: |
Hi,
I would like to use the DRS4 board with LabView for fast readout.
Do you know anyone who has written a VI for that?
Thanks,
Christian
|
|
Thu Nov 10 04:41:24 2016, Abhishek Rajput, Break Statements in DRS4 Binary to ROOT Macro
|
Hello,
I recently modified the binary to ROOT convertor written by Stefan (https://midas.psi.ch/elogs/DRS4+Forum/361) so it can decode data taken with any channel or set of channels on the DRS4. In the process of testing this modifed version for data taken on all 4 channels, I encountered problems with decoding some of the event data. More specifically, upon hitting a certain event in some channel, the histograms for that channel would no longer be filled and the histograms for subsequent channels would not be filled with any event at all.
After considerable bug hunting, I discovered the source of this problem was due to the break statement in the following code extract from the ROOT to binary macro:
for (n=0 ; n<5 ; n++) {
// read event header
i = fread(&eh, sizeof(eh), 1, f);
if (i < 1)
break;
For some events apparently, the event header fails to be read properly (fread line returns 0 in this case). Moreover, when I used the feof and ferror functions on a particular file I was testing, the feof function returned a value of 1.
So my questions deal with two scenarios.
Firstly, in the event of an fread error, is a break statement is necessary? Is it not possible to skip the voltage data for those events whose event header fails to be read properly? Or is it the case that when some "corrupted" event header is encountered, all waveform data subsequent to that event is likewise corrupted? If the former is the case, is it advisable to replace the break condition with an fseek line that advances the position indicator of the stream by an additional 2052*n_channels + 32 bytes (in accordance with the binary file specifications of page 25 on the DRS4 manual) so that the next set of voltage data can be read?
Secondly, in the case of an end of file error, does there exist any possible solution? Or is such an error an indication of a faulty drs4 channel or corrupted binary file?
Any help with the aforementioned issues would be greatly appreciated.
Abhishek
|
Thu Nov 10 09:56:04 2016, Stefan Ritt, Break Statements in DRS4 Binary to ROOT Macro
|
Hi,
fread() returns the number of bytes read and zero (I believe) if there is an end of file. So this break statement is a simple end-of-file test. There might be other erros such as hard disk failures, but these are extremely rare.
If course the file should not end in the middle of an event header. If it does, it means the file is corrupted and truncated, and we should not continue to read that file, that's why there is the break. The internal file is just a series of bytes, it does not know about the event header, so there will be no "error" if we have for example a missing event header but a voltage array. To be correct, the code should actually read
for (n=0 ; n<5 ; n++) {
// read event header
i = fread(&eh, sizeof(eh), 1, f);
if (i < sizeof(eh))
break;
Hope this helps,
Stefan
Abhishek Rajput wrote: |
Hello,
I recently modified the binary to ROOT convertor written by Stefan (https://midas.psi.ch/elogs/DRS4+Forum/361) so it can decode data taken with any channel or set of channels on the DRS4. In the process of testing this modifed version for data taken on all 4 channels, I encountered problems with decoding some of the event data. More specifically, upon hitting a certain event in some channel, the histograms for that channel would no longer be filled and the histograms for subsequent channels would not be filled with any event at all.
After considerable bug hunting, I discovered the source of this problem was due to the break statement in the following code extract from the ROOT to binary macro:
for (n=0 ; n<5 ; n++) {
// read event header
i = fread(&eh, sizeof(eh), 1, f);
if (i < 1)
break;
For some events apparently, the event header fails to be read properly (fread line returns 0 in this case). Moreover, when I used the feof and ferror functions on a particular file I was testing, the feof function returned a value of 1.
So my questions deal with two scenarios.
Firstly, in the event of an fread error, is a break statement is necessary? Is it not possible to skip the voltage data for those events whose event header fails to be read properly? Or is it the case that when some "corrupted" event header is encountered, all waveform data subsequent to that event is likewise corrupted? If the former is the case, is it advisable to replace the break condition with an fseek line that advances the position indicator of the stream by an additional 2052*n_channels + 32 bytes (in accordance with the binary file specifications of page 25 on the DRS4 manual) so that the next set of voltage data can be read?
Secondly, in the case of an end of file error, does there exist any possible solution? Or is such an error an indication of a faulty drs4 channel or corrupted binary file?
Any help with the aforementioned issues would be greatly appreciated.
Abhishek
|
|
Thu Nov 10 19:24:52 2016, Abhishek Rajput, Break Statements in DRS4 Binary to ROOT Macro
|
Hello,
I am wondering why the code should be changed to i < sizeof(eh), since doesn't fread(&eh,sizeof(eh),1,f) return 1 in this scenario? I've confirmed with a cout statement that this is the case, so this break condition will therefore always trigger as sizeof(eh) is 32 bytes.
Either way, I believe I figured out my problem. In my revised version of your code, I had two nested loops, the outer one being a loop over the channels and the inner one being a loop over the events. However, I really should have been doing the reverse considering the binary structure of the file. Otherwise, the end of the file will be reached for only a single iteration of the channel loop if I choose to loop through all the events in the data file.
Once I modified the code to have the outer loop be over all the events and the inner one be over all the channels, I no longer suffered from breaks in the loops.
Many thanks for your assistance.
Abhishek
Stefan Ritt wrote: |
Hi,
fread() returns the number of bytes read and zero (I believe) if there is an end of file. So this break statement is a simple end-of-file test. There might be other erros such as hard disk failures, but these are extremely rare.
If course the file should not end in the middle of an event header. If it does, it means the file is corrupted and truncated, and we should not continue to read that file, that's why there is the break. The internal file is just a series of bytes, it does not know about the event header, so there will be no "error" if we have for example a missing event header but a voltage array. To be correct, the code should actually read
for (n=0 ; n<5 ; n++) {
// read event header
i = fread(&eh, sizeof(eh), 1, f);
if (i < sizeof(eh))
break;
Hope this helps,
Stefan
Abhishek Rajput wrote: |
Hello,
I recently modified the binary to ROOT convertor written by Stefan (https://midas.psi.ch/elogs/DRS4+Forum/361) so it can decode data taken with any channel or set of channels on the DRS4. In the process of testing this modifed version for data taken on all 4 channels, I encountered problems with decoding some of the event data. More specifically, upon hitting a certain event in some channel, the histograms for that channel would no longer be filled and the histograms for subsequent channels would not be filled with any event at all.
After considerable bug hunting, I discovered the source of this problem was due to the break statement in the following code extract from the ROOT to binary macro:
for (n=0 ; n<5 ; n++) {
// read event header
i = fread(&eh, sizeof(eh), 1, f);
if (i < 1)
break;
For some events apparently, the event header fails to be read properly (fread line returns 0 in this case). Moreover, when I used the feof and ferror functions on a particular file I was testing, the feof function returned a value of 1.
So my questions deal with two scenarios.
Firstly, in the event of an fread error, is a break statement is necessary? Is it not possible to skip the voltage data for those events whose event header fails to be read properly? Or is it the case that when some "corrupted" event header is encountered, all waveform data subsequent to that event is likewise corrupted? If the former is the case, is it advisable to replace the break condition with an fseek line that advances the position indicator of the stream by an additional 2052*n_channels + 32 bytes (in accordance with the binary file specifications of page 25 on the DRS4 manual) so that the next set of voltage data can be read?
Secondly, in the case of an end of file error, does there exist any possible solution? Or is such an error an indication of a faulty drs4 channel or corrupted binary file?
Any help with the aforementioned issues would be greatly appreciated.
Abhishek
|
|
|
Thu Nov 10 22:07:40 2016, Stefan Ritt, Break Statements in DRS4 Binary to ROOT Macro
|
You're right, fread() return the number of objects read, so indeed it should be one if successful.
Abhishek Rajput wrote: |
Hello,
I am wondering why the code should be changed to i < sizeof(eh), since doesn't fread(&eh,sizeof(eh),1,f) return 1 in this scenario? I've confirmed with a cout statement that this is the case, so this break condition will therefore always trigger as sizeof(eh) is 32 bytes.
Either way, I believe I figured out my problem. In my revised version of your code, I had two nested loops, the outer one being a loop over the channels and the inner one being a loop over the events. However, I really should have been doing the reverse considering the binary structure of the file. Otherwise, the end of the file will be reached for only a single iteration of the channel loop if I choose to loop through all the events in the data file.
Once I modified the code to have the outer loop be over all the events and the inner one be over all the channels, I no longer suffered from breaks in the loops.
Many thanks for your assistance.
Abhishek
Stefan Ritt wrote: |
Hi,
fread() returns the number of bytes read and zero (I believe) if there is an end of file. So this break statement is a simple end-of-file test. There might be other erros such as hard disk failures, but these are extremely rare.
If course the file should not end in the middle of an event header. If it does, it means the file is corrupted and truncated, and we should not continue to read that file, that's why there is the break. The internal file is just a series of bytes, it does not know about the event header, so there will be no "error" if we have for example a missing event header but a voltage array. To be correct, the code should actually read
for (n=0 ; n<5 ; n++) {
// read event header
i = fread(&eh, sizeof(eh), 1, f);
if (i < sizeof(eh))
break;
Hope this helps,
Stefan
Abhishek Rajput wrote: |
Hello,
I recently modified the binary to ROOT convertor written by Stefan (https://midas.psi.ch/elogs/DRS4+Forum/361) so it can decode data taken with any channel or set of channels on the DRS4. In the process of testing this modifed version for data taken on all 4 channels, I encountered problems with decoding some of the event data. More specifically, upon hitting a certain event in some channel, the histograms for that channel would no longer be filled and the histograms for subsequent channels would not be filled with any event at all.
After considerable bug hunting, I discovered the source of this problem was due to the break statement in the following code extract from the ROOT to binary macro:
for (n=0 ; n<5 ; n++) {
// read event header
i = fread(&eh, sizeof(eh), 1, f);
if (i < 1)
break;
For some events apparently, the event header fails to be read properly (fread line returns 0 in this case). Moreover, when I used the feof and ferror functions on a particular file I was testing, the feof function returned a value of 1.
So my questions deal with two scenarios.
Firstly, in the event of an fread error, is a break statement is necessary? Is it not possible to skip the voltage data for those events whose event header fails to be read properly? Or is it the case that when some "corrupted" event header is encountered, all waveform data subsequent to that event is likewise corrupted? If the former is the case, is it advisable to replace the break condition with an fseek line that advances the position indicator of the stream by an additional 2052*n_channels + 32 bytes (in accordance with the binary file specifications of page 25 on the DRS4 manual) so that the next set of voltage data can be read?
Secondly, in the case of an end of file error, does there exist any possible solution? Or is such an error an indication of a faulty drs4 channel or corrupted binary file?
Any help with the aforementioned issues would be greatly appreciated.
Abhishek
|
|
|
|
Fri Nov 4 17:41:03 2016, Christian Farina, Missing Header
|
Hello everybody,
I am completely new to this, so please bear with me.
I am trying to install the applications on my laptop. I downloaded and untar-ed the drivers and applications for Linux as described in the evaluation board manual. However, when I do the make, I get the following error:
drs-4.0.0$ make
g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -DOS_LINUX -DHAVE_LIBUSB -DUSE_DRS_MUTEX -c src/musbstd.c
In file included from src/musbstd.c:14:0:
include/musbstd.h:17:17: fatal error: usb.h: No such file or directory
#include <usb.h>
Can anybody help me please?
Thanks. |
Tue Nov 8 10:20:52 2016, Stefan Ritt, Missing Header
|
The web page from where you downloaded the software contains a sentence "requires libusb-1.0 package". Please install it. This package brings the "usb.h" header file.
Stefan
Christian Farina wrote: |
Hello everybody,
I am completely new to this, so please bear with me.
I am trying to install the applications on my laptop. I downloaded and untar-ed the drivers and applications for Linux as described in the evaluation board manual. However, when I do the make, I get the following error:
drs-4.0.0$ make
g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -DOS_LINUX -DHAVE_LIBUSB -DUSE_DRS_MUTEX -c src/musbstd.c
In file included from src/musbstd.c:14:0:
include/musbstd.h:17:17: fatal error: usb.h: No such file or directory
#include <usb.h>
Can anybody help me please?
Thanks.
|
|
Wed Nov 9 17:19:48 2016, Christian Farina, Missing Header
|
Thank you Stefan, that was just what I needed.
Also, I have another question, if I am allowed to ask on this forum. I am trying to study how the time calibration of the DRS is done. Can you point me to the script in which this is done?
Thank you,
Christian
Stefan Ritt wrote: |
The web page from where you downloaded the software contains a sentence "requires libusb-1.0 package". Please install it. This package brings the "usb.h" header file.
Stefan
Christian Farina wrote: |
Hello everybody,
I am completely new to this, so please bear with me.
I am trying to install the applications on my laptop. I downloaded and untar-ed the drivers and applications for Linux as described in the evaluation board manual. However, when I do the make, I get the following error:
drs-4.0.0$ make
g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -DOS_LINUX -DHAVE_LIBUSB -DUSE_DRS_MUTEX -c src/musbstd.c
In file included from src/musbstd.c:14:0:
include/musbstd.h:17:17: fatal error: usb.h: No such file or directory
#include <usb.h>
Can anybody help me please?
Thanks.
|
|
|
Wed Nov 9 19:49:07 2016, Stefan Ritt, Missing Header
|
Best is to read this paper: https://arxiv.org/abs/1405.4975
The source code for that is in DRS.cpp in the DRS software distribution in the function DRSBoard::CalibrateTiming()
Stefan
Christian Farina wrote: |
Thank you Stefan, that was just what I needed.
Also, I have another question, if I am allowed to ask on this forum. I am trying to study how the time calibration of the DRS is done. Can you point me to the script in which this is done?
Thank you,
Christian
Stefan Ritt wrote: |
The web page from where you downloaded the software contains a sentence "requires libusb-1.0 package". Please install it. This package brings the "usb.h" header file.
Stefan
Christian Farina wrote: |
Hello everybody,
I am completely new to this, so please bear with me.
I am trying to install the applications on my laptop. I downloaded and untar-ed the drivers and applications for Linux as described in the evaluation board manual. However, when I do the make, I get the following error:
drs-4.0.0$ make
g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -DOS_LINUX -DHAVE_LIBUSB -DUSE_DRS_MUTEX -c src/musbstd.c
In file included from src/musbstd.c:14:0:
include/musbstd.h:17:17: fatal error: usb.h: No such file or directory
#include <usb.h>
Can anybody help me please?
Thanks.
|
|
|
|
Thu Nov 10 20:54:45 2016, Christian Farina, Missing Header
|
Hi Stefan,
I have already read the paper. I was just unsure where the calibration code was located. Thank you so much for all your help.
Christian
Stefan Ritt wrote: |
Best is to read this paper: https://arxiv.org/abs/1405.4975
The source code for that is in DRS.cpp in the DRS software distribution in the function DRSBoard::CalibrateTiming()
Stefan
Christian Farina wrote: |
Thank you Stefan, that was just what I needed.
Also, I have another question, if I am allowed to ask on this forum. I am trying to study how the time calibration of the DRS is done. Can you point me to the script in which this is done?
Thank you,
Christian
Stefan Ritt wrote: |
The web page from where you downloaded the software contains a sentence "requires libusb-1.0 package". Please install it. This package brings the "usb.h" header file.
Stefan
Christian Farina wrote: |
Hello everybody,
I am completely new to this, so please bear with me.
I am trying to install the applications on my laptop. I downloaded and untar-ed the drivers and applications for Linux as described in the evaluation board manual. However, when I do the make, I get the following error:
drs-4.0.0$ make
g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -DOS_LINUX -DHAVE_LIBUSB -DUSE_DRS_MUTEX -c src/musbstd.c
In file included from src/musbstd.c:14:0:
include/musbstd.h:17:17: fatal error: usb.h: No such file or directory
#include <usb.h>
Can anybody help me please?
Thanks.
|
|
|
|
|
|