Difference between revisions of "IntegrationDaq 240405"
From Moller Wiki
(→Open Issues to be followed up later) |
(→Open Issues to be followed up later) |
||
| Line 24: | Line 24: | ||
#* For the latency synchronization, we would want to be able to get all of the ADC samples representing the helicity window, and would want to have this available in as many channels as possible. | #* For the latency synchronization, we would want to be able to get all of the ADC samples representing the helicity window, and would want to have this available in as many channels as possible. | ||
#** We don't need every helicity window read out | #** We don't need every helicity window read out | ||
| − | #** We need to be able to compare the waveforms for different channels all referenced to the | + | #** We need to be able to compare the waveforms for different channels all referenced to the integrate-start for their module |
| − | #** This seems like it is different from the full streaming mode: we just want a waveform of a specific number of samples triggered by the | + | #** This seems like it is different from the full streaming mode: we just want a waveform of a specific number of samples triggered by the integrate-start. But does it need to be a separate mode? |
| + | #*** If using the streaming mode, how do we synchronize the streams for multiple modules, and how do we recognize the integrate-start | ||
== Minutes == | == Minutes == | ||
Revision as of 15:38, 5 April 2024
Back to Main Page >> Data Acquisition Meetings >> Integrating mode DAQ meetings
previous meeting << >> following meeting
Meeting information
Meeting time: 1:00pm Eastern Zoom connection information is sent out by email; please reach out to Paul if you don't have the current link.
Agenda
- Activity updates
- General discussion
Open Issues to be followed up later
- Discussions with M. Pitt & J. Musson to understand the beam monitor signals we'll be getting
- Draft timing diagram: DocDB 790
- Michael, Bob, Brynne, and Paul should put together a list of the integrator running modes we would like to have available
- To keep the data volume manageable, we'd like to use 32-bit words for the accumulated values we transfer when running at the ~2kHz. A 32-bit word would overflow after 16384 18-bit samples are accumulated. At the nominal 14.7MHz sampling rate, this is an integration period of about 1.1us.
- If we wanted to support longer integration periods, such as during parasitic testing in-beam, what is best choice:
- Accumulate in 32-bit words, but change the setting of the effective sampling rate so that we wouldn't saturate
- Apply an software-selectable bit shift to the ADC values before they are accumulated in 32-bit words
- Accumulate the sums in 64-bit words, but have an option to either transfer just the low 32-bits or transfer the full 64 bits.
- If we wanted to support longer integration periods, such as during parasitic testing in-beam, what is best choice:
- For the latency synchronization, we would want to be able to get all of the ADC samples representing the helicity window, and would want to have this available in as many channels as possible.
- We don't need every helicity window read out
- We need to be able to compare the waveforms for different channels all referenced to the integrate-start for their module
- This seems like it is different from the full streaming mode: we just want a waveform of a specific number of samples triggered by the integrate-start. But does it need to be a separate mode?
- If using the streaming mode, how do we synchronize the streams for multiple modules, and how do we recognize the integrate-start
- To keep the data volume manageable, we'd like to use 32-bit words for the accumulated values we transfer when running at the ~2kHz. A 32-bit word would overflow after 16384 18-bit samples are accumulated. At the nominal 14.7MHz sampling rate, this is an integration period of about 1.1us.
Minutes
Recording at zoomgov:
Participants:
