Difference between revisions of "FA125 Data Format June 23, 2015"
From GlueXWiki
(→Minutes) |
(→Minutes) |
||
| Line 64: | Line 64: | ||
Present: Naomi, Mike (CMU), Beni, Simon, Lubomir (JLab) | Present: Naomi, Mike (CMU), Beni, Simon, Lubomir (JLab) | ||
| − | #Update from Cody last week - he synthesized the CDC combined mode and got some real (eventless) data through his test card using it - | + | #Update from Cody last week - he synthesized the CDC combined mode and got some real (eventless) data through his test card using it - headers, trigger time and trailer (he suppressed the event data just to make testing easier in these early stages). This shows that both the new daisy chain and backend architectures work. It looks like he will have to make separate CDC and FDC versions to get the firmware to fit onto the card. When he gets back he'll talk to Bryan about the driver. |
# We need to add a parameter NPK (for number of peaks) to the firmware/driver spec. Multiple-peak-per-trigger reporting is already in the firmware, but undocumented. At present the max value for NPK is 512 but to prevent data deluge due to accidental typos we would like to limit this to a smaller number, we picked 8. The firmware would only record the peaks found in the window. After the first threshold crossing, the peak search requires a maximum after a minimum; falling below threshold is not required. Each maxima is identified as the sample before 2 consecutive decreasing samples. | # We need to add a parameter NPK (for number of peaks) to the firmware/driver spec. Multiple-peak-per-trigger reporting is already in the firmware, but undocumented. At present the max value for NPK is 512 but to prevent data deluge due to accidental typos we would like to limit this to a smaller number, we picked 8. The firmware would only record the peaks found in the window. After the first threshold crossing, the peak search requires a maximum after a minimum; falling below threshold is not required. Each maxima is identified as the sample before 2 consecutive decreasing samples. | ||
# We should make sure that in the combined data formats, the firmware is reporting the calculated quantities for each peak but including the raw samples only once. | # We should make sure that in the combined data formats, the firmware is reporting the calculated quantities for each peak but including the raw samples only once. | ||
Revision as of 11:26, 24 June 2015
Location and Time
Room: CC F326
Time: 2pm.
Remote Connection
You can connect using BlueJeans using the meeting number 589 693 655 . (Click "Expand" to the right for more details -->):
(if problems, call phone in conference room: 757-269-6460 might not be the correct number)
- To join via Polycom room system go to the IP Address: 199.48.152.152 (bjn.vc) and enter the meeting ID: 589693655.
- To join via a Web Browser, go to the page [1] https://bluejeans.com/589693655.
- To join via phone, use one of the following numbers and the Conference ID: 589693655
- US or Canada: +1 408 740 7256 or
- US or Canada: +1 888 240 2560
More information on connecting to bluejeans is here
Specific instructions for connecting via polycom:
- Turn polycom on if necessary
- With the polycom, place a call at 199.48.152.152
- Press # to enable the polycom keypad, then enter the meeting id: 589693655 and #
- You may have to unmute the microphone: #*4
- Turn the computer on if needed
Agenda
- Previous meeting (June 9, 2015)
- Status of FADC125 Firmware (report from Cody last week is in the minutes)
- Version 5.06, 23 June 2015
- Need to add NPK for number of peaks
- Need to eliminate unnecessary data modes
- Parameter PG to describe gap between pedestal sample and threshold crossing (replaces XTHR in user interface)
- Pedestal samples
Useful Links
- Timing algorithm - updated to include latest revisions
- fADC125 Data Format Specification Document
- Ver 5.01 in svn, 17 Feb 2015
- Version 5.03, 11 March 2015
- Version 5.06, 23 June 2015
- Data format for 250 modes on fADC125 from Cody, Aug 15 2014
- FA250 modes 2 from Ed and Hai, Feb 18 2014
- FIRMWARE for FADC250 Ver2 ADC FPGA, Sept 2014?
- FDC_pulse_data_format
- CDC readout needs Garfield calcs
- CDC_run_985 CDC_run_970
Minutes
Present: Naomi, Mike (CMU), Beni, Simon, Lubomir (JLab)
- Update from Cody last week - he synthesized the CDC combined mode and got some real (eventless) data through his test card using it - headers, trigger time and trailer (he suppressed the event data just to make testing easier in these early stages). This shows that both the new daisy chain and backend architectures work. It looks like he will have to make separate CDC and FDC versions to get the firmware to fit onto the card. When he gets back he'll talk to Bryan about the driver.
- We need to add a parameter NPK (for number of peaks) to the firmware/driver spec. Multiple-peak-per-trigger reporting is already in the firmware, but undocumented. At present the max value for NPK is 512 but to prevent data deluge due to accidental typos we would like to limit this to a smaller number, we picked 8. The firmware would only record the peaks found in the window. After the first threshold crossing, the peak search requires a maximum after a minimum; falling below threshold is not required. Each maxima is identified as the sample before 2 consecutive decreasing samples.
- We should make sure that in the combined data formats, the firmware is reporting the calculated quantities for each peak but including the raw samples only once.
- The format spec mentions output of samples in the 'pulse window' for the combined format. This should be the entire trigger window.
- We do not need the raw sample data formats (window or pulse raw data) as the raw samples are included in the combined formats.
- We do not need the scaler data format.
- The data modes are not listed in the spec and should be.
- We are happy to use the parameter PG to describe gap between pedestal sample and threshold crossing (which replaces XTHR in user interface) and can use the figures above (or create more) to pick the best value for a given threshold by looking to see where the signals before the pulse diverge.
- Pedestal samples - Beni found no significant difference between using integer mean pedestal and floating point mean pedestal for subtraction from the integral. He found some strange effects using different batches of pre-pulse pedestal samples, the mean was lowest at the start of the data window.
- Lubomir pointed out that if we integrate from the start of the pulse to a fixed number of samples after the threshold crossing, we don't know how many samples we integrated because the threshold crossing is not output. We will have to fix this. [eg by integrating for a fixed number of samples after the start of the pulse, not the threshold crossing]
