Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
daq:s800loss [2012/05/18 10:34] scott [Progress] |
daq:s800loss [2014/02/27 16:14] (current) |
||
|---|---|---|---|
| Line 6: | Line 6: | ||
| ====== Progress ====== | ====== Progress ====== | ||
| + | |||
| + | ==18th May 2012:== | ||
| 1. Beginning data (first event): will be investigated week of 21st May - 25th May | 1. Beginning data (first event): will be investigated week of 21st May - 25th May | ||
| Line 12: | Line 14: | ||
| A few 10s of events could have been lost by a bug in the s800 event builder code preventing the output of the last buffer. This is now fixed (18th May 2012). | A few 10s of events could have been lost by a bug in the s800 event builder code preventing the output of the last buffer. This is now fixed (18th May 2012). | ||
| - | A number of triggers (of the order of 10 @ 1.5kHz) can be accepted by the Gretina but not s800 at the end of the run. This is due to a hardware limitation of the CCUSB CAMAC crate controller. While in running mode (daq mode) it cannot send a command to the trigger module to stop triggers. The order has to be: switch out of daq mode, stop triggers. There will, therefore, always be a number of triggers not accepted by the s800 daq that make it to the Gretina daq. This can be mitigated by requiring in the data sorting that good events have a Gretina and s800 event present (which already needs to be done in order to build the timestamp ordered subevents into events, from the data produced by the Gretina Global Event Builder). The high resolution run time can then be determined by the timestamp difference between the last and first good event. This is simply equivalent to ending the run a few microseconds earlier. | + | A number of triggers (on the order of 10 @ 1.5kHz) can be accepted by the Gretina but not s800 at the end of the run. This is due to a hardware limitation of the CCUSB CAMAC crate controller. While in running mode (daq mode) it cannot send a command to the trigger module to stop triggers. The order has to be: switch out of daq mode, stop triggers. There will, therefore, always be a number of triggers not accepted by the s800 daq that make it to the Gretina daq. This can be mitigated by requiring in the data sorting that good events have a Gretina and s800 event present (which already needs to be done in order to build the timestamp ordered subevents into events, from the data produced by the Gretina Global Event Builder). The high resolution run time can then be determined by the timestamp difference between the last and first good event. This is simply equivalent to ending the run a few microseconds earlier. |
| Another effect is due to the order in which the pushToGeb process and Gretina stop is done, and communication between these actions. This could have lead to valid s800 events not making it to the GGEB during testing in the week of 14th May - 18th May. Ron Fox is optimising this, and it will be further tested in the week of 21st May. Final conclusions will be updated here following the conclusion of that testing. | Another effect is due to the order in which the pushToGeb process and Gretina stop is done, and communication between these actions. This could have lead to valid s800 events not making it to the GGEB during testing in the week of 14th May - 18th May. Ron Fox is optimising this, and it will be further tested in the week of 21st May. Final conclusions will be updated here following the conclusion of that testing. | ||
| + | |||
| + | ==30th May 2012:== | ||
| + | |||
| + | Kathrin reported last week that a test run no longer had the missing first event. The last event was not complete (s800 data seemed to end prematurely before packet end) but it was not certain if this was a coding error or transfer error. Ron is still working on his modifications, so a total integration test is scheduled for the week beginning 4th June 2012. | ||
