-----Original Message----- From: Allison, Stephanie Sent: Wednesday, June 19, 2002 9:58 AM To: Smith, Steve; Frisch, Josef C.; Kim, Kukhee; Allison, Stephanie Cc: Luchini, Kristi; Chestnut, Ronald P.; Ross, Marc; Nelson, Janice L.; Rock, Judith E.; Laznovsky, Michael; Zhou, Jingchen Subject: SIS Digitizer Software Requirements Hello - Joe, Steve, Kuhkee, and Steph met June 18 to discuss the SIS digitizer software. Here are my notes with additional thoughts added after the meeting: Raw Data Acquisition and SIS Setup Requirements ----------------------------------------------- The SIS digitizer hardware will be acquiring pulse-by-pulse data on trigger provided by a PDU. The hardware will be setup so that 400-512 points per pulse for the last 3 pulses will be kept in its own ring-buffer. The triggers will stop when fast RF processing detects a fault and pulls a permit on the VMIC DIO->NIM->PDU. The SIS software ONLY needs to read the last-3-pulse-data when told to do so by fast processing sometime (ie, 1 second) after it pulls the permit. So fast processing will trigger EPICS processing of the passive SIS waveform records at the proper time in the proper sequence. There is no requirement for interrupt-driven waveform acquisition or even interrupt processing at all. There is no requirement to constantly and unnecessarily stream the data from the digitizer across the VME backplane into IOC memory. There is a requirement that we process a user-request for snapshot waveforms. This will be achieved in one of two ways: (1) We either interrupt RF processing for a short time by pulling the permit OR (2) We continue RF processing but somehow temporarily disable the SIS triggers, get the data, and reenable the triggers. If a fault just happens to occur during this time, we do not record the trip but still recover normally. Joe Frisch will discuss both options with Marc Ross. If possible, Joe would like the ability to set internal or external clock from an EPICS display for potential future use. This is a low priority task. We need the ability to access status and other diagnostic information from the SIS. Ideally, we want a VME record for each SIS digitizer with fields for status and other status readback, like was done for the NLCTA Joerger. Database and Online Processing Requirements ------------------------------------------- Once the SIS digitizer waveforms are filled in, subsequent processing will be done before trip recovery begins. The sequence of processing will look something like this: (1) Waveforms with raw data are filled. (2) Waveforms with scaled I and Q data are calculated from (1). (3) Waveforms with phase and power will be calculated from (2). (4) EPICS PVs will be provided for calibration constants used in (1) and (2) and will include: I and Q offsets, I and Q gains, quadrature angle (5) It may be necessary to split some or all of the waveforms in (1), (2), or (3) into 3 separate waveforms, one per pulse. (6) EPICS PVs will be derived from the power waveforms for quantities including: Peak power, total energy(?), RMS power(?) Are these per pulse? (7) Copies of various waveform and scalar PVs are made to other PVs so that the user has online access to the data of the last 6 faults from an EPICS display or any other CA client. (8) Fast processing will wait for a generous amount of time for all acquisition/processing/storage of all waveforms to complete before starting the ramp back up. It is expected that the entire process will take less than 10 seconds. Calibration Requirements ------------------------ Calibration may be done via matlab script. If it is simple and well-defined, we may put the calibration procedure in the IOC as either an EPICS sequence or a sequence of database records. TBD............. Real-Time Display/Alarm/Config Requirements ------------------------------------------- TBD........ Storage Requirements -------------------- Once all the waveforms are read and processed, a CA client will acquire the waveforms over the network and store them for future offline analysis. For now, we are assuming that the CA client will be the archive engine and storage mechanism will be Oracle. If for some reason, this scheme is not available in time for our use, one contingency will be to use the archive engine and binary files with some sort of backup mechanism. The archived data will include: (1) Waveforms with raw data (2) All calibration constants (3) Unique timestamp (only if we can store string data?) and pulseID/counter identifying the fault. (4) Derived quantities like peak power. (5) Did we also want to store the phase/power waveforms? Retrieval and History Browser Requirements ------------------------------------------ Retrieval mechanisms will be provided for all data stored in step (8) so that specified data can be dumped to a matlab or ascii file over a specified time period. The file will be created on Unix NFS data server or toaster space and no backup will be provided. The file will be automatically deleted after a certain time period. If offline analysis is done on a system without access to this NFS data server, then users must manually copy (ie, ftp) the files over. A browser will be provided to preview the data. Currently, we plan that for scaler data, the NLCTA python browser will be used, and for waveform data, the web CGI export browser (still in testing) will be used. We hope that a better browser that will handle both scalar and waveform data will be made available. --------------------------------------------------------------------------------- Any comments are welcome. Kuhkee is proceeding with the design involved in the first section (SIS Raw Data Acq and Setup) which is for a driver and device support for the raw data waveform, output records needed for setup, and the diagnostic VME record with status fields. Thanks, Stephanie