This chapter describes data sources and leads you through the construction of a sample data source. This chapter will require that you:
Have an understanding of the way C++ implements inheritance
Understand C++ virtual functions
Have a low level understanding of the Unix make utility and Makefiles.
Be able to construct simle electronics setups
Be able to use an oscilloscope
Have access to a data acquisition spdaq system on which you can run the sample data source we construct.
The top level organization of this chapter is as follows:
Data sources and what they do are introduced.
The High performance production readout skeleton is introduced.
We work a simple example to read the channels of a CAEN V775 TDC.
We introduce event packets and their role in building larger systems. We modify the CAEN V775 example so that it produces its event segment in a documented packet.
We describe the typical role of periodically read scalers, and add a set of scalers to our sample readout.
We describe how to add an event segment for legacy readout software that has been built on the Readout Classic framework.
In addition, while testing and demonstrating our data source, we will introduce bufdump a formatted buffer dumper.
The NSCL Data acqusition system model is that a single source of events produces data that are distributed to an arbitrary set of clients computers and event sink programs within those computers. The NSCL Data acquisition system implements data sources as single programs that have several clear responsibilities. Event sources are often called Readout programs by users of the system since the default build procedures result in an executable named Readout.
Event sources are responsible for acquiring data from the experiment hardware in response to event triggers. This requires that event sources run in computers that are physically attached to the experimental hardware. At the NSCL, these systems are referred to as spdaq systems because they generally have names like spdaqnn.
The manner in which the event source interacts with the event trigger is highly experiment dependent. Other responsibilities of the event source are completely experiment independent. Events are collected into larger, fixed sized, blocks of data called buffers. These buffers are submitted to spectrodaq which distributes them to the event sinks.
In addition to these data taking responsibilities, the event source must react to control requests to start and stop data taking. It must be able to store and record some documentation about the run (minimally a title and run number), and in some cases add data from additional non event sources to the data stream pushed through spectrodaq.
This mix of experiment dependent and experiment independent responsibilities is one reason that event sources are implemented as application frameworks. If you are not familiar with the term "application framework", see the description of application frameworks in the previous chapter. This description may save you some confusion.
Implementing data sources as application frameworks separates the experiment dependent and independent responsibilities of data sources. This separation is done in a way that ensures that the experiment independent responsibilities are correctly handled for you leaving you free to think only about correctly implementing your experiment dependent responsibilities.