View source for IntegrationDaq 240405

__NOTOC__
Back to [[Main_Page|Main Page]] >>  [[DAQ Meetings|Data Acquisition Meetings]] >>  [[DAQ Meetings#Integrating mode DAQ meetings|Integrating mode DAQ meetings]]

[[IntegrationDaq_240322 | previous meeting]] <<   >> [[IntegrationDaq_240419 | 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: [https://moller.jlab.org/cgi-bin/DocDB/public/ShowDocument?docid=790 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.1ms.
#** 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.
#*  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

== Minutes ==
Recording at zoomgov:  

Participants:  R. Michaels, P. King, W. Gu, B. Blaikie, J. Pan, S. Chatterjee, D. Bishop, H. Liu, K. Dehmelt, A. Sen, M. Gericke, Jaydeep, D. McNulty, Bryerton (joined at the very end)

*  Status of the specification document
**  Discussion of the accumulation
***  Daryl asks if we could use some sort of loss-less compression.
***  Michael asks how long integration periods the 64-bit words would be.  I note that If we just want to support 1/30s windows, we'd probably only really only need 40-bits as the data structure elements
*  Brynne has been making progress on the cross-talk tests, but does not have the analysis of it ready to be presented yet
*  Michael asks Daryl about the set of switches on the module near the SoM.  Those switches are used to configure the reference clock.  Having them in the "proper" setting will only really matter if we're comparing two modules at the same time.
**  There is another switch on the board, which just controls if the chassis fans are using the internal or external power supply.  The CPU fan is always powered from the internal supply.
*  Michael thinks that we should have a chassis fan.
**  Discussing where to put a chassis fan.  Daryl says most of the heat will be on the right side (near the SoM), so that would be where we would want the fan.
**  William suggests putting a fan to pull air into the chassis on the left and have it push out to the left.
*  Discussing the ADC chassis.
**  There is a screw lug that can be used to connect the safety ground to the chassis.  S
*  Michael asks about the TI card order.  The cards need to go fist to William for the final assembly.
*  Final discussion with Bryerton
**  Here recommends that the FPGA code would always store into 64-bit based data and then convert to 32-bits on the CODA/CPU
**  I will try to summarize waht my ideal settings woudl be and send that for discsussion