Page History
...
- DAQ wants: a run trigger (always running), acq-width, DAQ trigger. NEW: Image needs to be timestamped with the DAQ trigger timestamp.
- action item for DAQ: if we're running "normally" (no integration) what needs to change on the DAQ end?
- need to have run trigger timestamp in the data passed back
- acq_width has a precision of 10ns (detector clock). small compared to 1us time between shots, so should be precise enough to identify shots, even with clock-domain-crossing jitter
- Dionisio looked at HR longer integration times: boards have just arrived back. perhaps done in next 2 weeks.
- Lorenzo looked at M longer integration times: could only study up to 20us because firmware hard to change. measured noise and pedestal shift and extrapolate.
- when can he go to longer times? needs prototype board. few months.
- andy wants to distinguish at the 1 photon level, ideally half photon level. 800eV photon is 200electrons. Georgi was 285eV, so 85 electrons so 2-sigma above the 35 electrons lorenzo predicts at 400us integration time. Georgi is OK with it since they're not interested in single photon information when integrating.
- may have better noise performance with next-gen boards
- Andy Aquila use-case: metric: number of photons per pulse times rep rate (number of photons per second)
- spectrometer is only use case
- expects shorter integration times
- low fluence (1 photon per pixel per shot) (~100 photons per 1000 pixels). integrating over 100-300 shots would be fine. maximum occupancy is one photon per pixel per shot.
- probably run at 300kHz max
- dionisio: in high gain 400us (high gain), less in medium gain
- Georgi use-case:
- is it beneficial to integrate? maybe not. Chris K. argues yes: since the beam rate helps so much, vs. the noise penalty
- not important to see single photons
- important to know which pulses contributed to image
- For deadtime vs. framerate: always have readout deadtime
- livefraction=(integrationtime-20us)/(150us(readout time)+24us(presampletime)+integrationtime)
- there may be limitations on what the accelerator will allow the experiments to do vis-a-vis beam-kicking (e.g. the dump can't take the full beam-rate)
- could timing system put sequence in the config object? can't trivially put the sequence-generating-code in the config object, but can see the result: the event codes in the timing-system data.
Slides from Lorenzo showing behavior of epixM noise vs. integration time (up to the 20us he could currently reach):
View file name 20220428_ePixM_integ.pptx height 250
To do list:
- epixHR noise measurements vs. integration time
- Longer term (months) epixM noise measurements vs. integration time
- make sure not too much has to change for DAQ between integrating-mode and "normal" mode
- camera shouldn't change
- just have to switch between running a sequence and normal running
...
Overview
Content Tools