Jola's Email from tonight:

PS: Igor was at XFLE today afternoon. We manage to create bunch structure pattern with vetos which maybe can allow us 

to get 28 or 29 x-ray pulses running detector with 2xrays_60cbi.txt pattern. We could not test it with x-rays, beacuase there was no xrays,

but thats all what we have at the moment.“

XFEL documentation

All documentations for XFEL is available here:

Interesting for us is the data analysis part:

From Aschkan's email:

At the moment it looks like we cannot take current source data at xfel at all and it could be we have to rely on the current source data we took previously in hour lab. I discussed this already with Torsten and we should make sure we have our lab data processed and in place asap.

Status as of 17:00:

Lab data has been processed for all modules installed at SPB, and can be found in the standard place on the GPFS.  I do not know what "in place" means...



This data should be really used only as a last resort in my opinion, for several reasons:

  1. Most modules have at least one ASIC where we don't have data for the "correct" current.  This means there are entire ASICs where we have (almost) no gain information!!!
    These are listed as "Bad ASICs" in the diagram below.
  2. The data was taken at different temperatures, ranging from -15C to -25C

Current configuration of SPB (click on a module to go to the detail page):

Color reflects the "official" grade of the module.


Flatfields taken for 30 memory cells at different intensities of the primary beam. Large areas do not see xrays since other devices are in the way. It is not possible to clear the path.

We took flat fields for 30 memory cells as we will probably not have current source dynamic range scans and cannot cross calibrate from one cell to the rest. Please note that because XFEL is running at 1.13MHz and the detector at 4.5MHz, only every 4th memory cell sees photons.

At the end of this blog entry you find a copy from the ELOG with a documenation of all run numbers. Please share the data with Valerio, Anton and PSI as well.

Here the run numbers of the flatfields we took for different transmission values. Please note that the transmission in percent is only an estimate and SPB has to verify them:

username: agipd_user


Sun Sep 10 12:29:10 2017: Run r0376 (3k) - dark data in the configuration for flat field (00.h5-08.h5 file for each module is "dark", from file 9 the shutter was opened)--> all 16 modules

Sun Sep 10 12:53:20 2017:waiting for the beam

Sun Sep 10 14:14:15 2017 :Run r0377 (3k) and r0378 (3k) - flat field with Cu foil 25um  maximum intensity --> all 16 modules

:Sun Sep 10 14:14:15 2017 :Run r0379 (3k) and r0380 (3k) - flat field Cu foli 25um + attenuator  (transmission 11.6 %-)> all 16 modules + some DA01 files 

Sun Sep 10 14:45:33 2017 Run r0381 (3k) and r0382 (3k) - flat field Cu foli 25um + attenuator  (transmission ~ 5 %) --> all 16 modules

Sun Sep 10 14:54:32 2017: Run r0383 (3k) and r0384 (3k) - flat field Cu foli 25um + attenuator  (transmission 1.6%)--> all 16 modules 

Sun Sep 10 15:15:18 2017 Run r0385 (3k) and r0386 (1.7k) - flat field Cu foli 25um +attenuator (transmission 15%)--> all 16 modules 

Sun Sep 10 15:24:34 2017 Go to 30 bunch mode,

Sun Sep 10 15:25:10 2017: Run r0388 (3k) and r0389 (3k) - flat field Cu foli 25um + attenuator  (transmission 5%)--> all 16 modules  (30 bunch mode)

Sun Sep 10 15:43:30 2017:  Run r0390 (3k)  - flat field Cu foli 25um + attenuator  (transmission 19%)--> all 16 modules  (30 bunch mode)

Sun Sep 10 15:49:53 2017: Run r0391 (3k)  - flat field Cu foli 25um -maximum intensity --> all 16 modules  (30 bunch mode)

Water ring found

Left: Baseline corrected mean of 3000 data points. Data was taken with 60 memory cells but note that XFEL was operated in single bunch mode and the single pulse hit only memory cell 4 (position 8 in array). The big dark blocks are due to an old pedestal map which was taken at a time when we had problems with the ASIC power of these ASICs. 

Right: Histograms over all pixels for all 16 modules.

Waiting for beam to take Cu flat fields.

I am not in on Monday and Tuesday! Here some open SPB topics for the next days:

Persons in brackets are responsible persons. Do not hesitate to call in further help if you need. The plan was discussed with Jola as well.


Processing Cu k_alpha data (Manuela, Jenny, Torsten)

  • Flat field data is taken. Data must be processed before the beam time starts in order to be able to correct at least the high gain of the detector during the beam time. As we will probably not have current source data for all memory cells by thursday, we took xray Cu data for 30 memory cells. So, we can at least directly calibrate the high gain and dont rely on internal sources. The run numbers are listed in a separate blog entry and I will ask ITDM to copy the runs to the offline folder /gpfs/exfel/exp/SPB/201730/p900009/usr/raw/. The entire calibration team should have access to this data already.
  • It turns out that flat fields are not possible without shadows of other devices. Therefore, please keep the gain maps we obtained in our lab as a fall back solution.
  • Please provide data also to PSI and include them into the data analysis. (Davide is at CFEL)
  • Please involve Jola and Steffen as well

Change of read out scheme (Alexander, Ulrich, Jola/Steffen)

  • It should be tested if we can change the readout scheme to this fits better to the DAQ chain of XFEL. However, first tests showed that this is only possible when reading out 352 images as otherwise the DAQ messes up the data. AAADDD for 60 bunches is not possible. On this topic it was not tested yet if the internal timings of the pattern cope with the C&C and if we actually see xray pulses with the AAADDD pattern. As X-rays are mandatory for this test, the only time is monday 5am-3pm. Please be at SPB at 9am.
  • The current ADADAD pattern can be considered as fall back solution.


Continue processing of Cu k_alpha data (Manuela, Jenny, Torsten)

  • Flat field data is taken. Data must be processed before the beam time starts in order to be able to correct at least the high gain of the detector during the beam time. As we will probably not have current source data for all memory cells by thursday, we took xray Cu data for 30 memory cells. So, we can at least directly calibrate the high gain and dont rely on internal sources. The run numbers are listed in a separate blog entry and I will ask ITDM to copy the runs to the offline folder /gpfs/exfel/exp/SPB/201730/p900009/usr/raw/. The entire calibration team should have access to this data already.

Current source scans (DRSCS) (Alexander, Ulrich, Igor, Jola)

It turned out that for every 22nd image in the data injected lines are not interrupted. This points towards a phase/timing problem between pattern/firmware/clock and control/readout and god knows what else.

  • How does every 22nd image look in detail? How do dynamic range scans look like? (Manuela)
  • The pattern used for DRSCS loops 1800 times with an increment of 10clks. This is wrong. I already provided a clock and control version of the DRSCS we use in our lab with 200 steps at 1clk increment and 1100 steps at 10clk increment. It was not tested yet, since their is beam available at the moment and other things have to be tested. The pattern should be tested Monday or Tuesday. (Jola, Alexander, Manuela)
  • Pattern to test: 1drs_cs_acsi15_xfel.txt
  • On the long term Jola and I were discussing the idea that the Firmware should have a "calibration mode" in which it does not listen to clock and control AND creates artificial train and bunch IDs since otherwise the PC layer will not understand the incoming data and could/will crash. (Not next week:)) (Igor, all, tbd on my return)
  • Create and test a new Current source pattern with burst readout based on the 200plus1100 writing scheme and compatible with C&C and PC layer. (Alexander)
  • Davide and Dominic are working on our single module system to optimise the current source injection patterns in order to reduce capacitive coupling. Discuss new injection pattern with Dominic, Davide, Manuela and Alexander. If a different injection sequence improves the dynamic range scans significantly, changes must be discussed with the calibration team and in particular with Manuela in order to adapt the gather scripts accordingly.
  • Igor is currently on vaccation but is on call and would potentially come in for a test of the current source. Please get in touch with him (if you dont have his number, please ask Heinz to call him)


Continue processing of Cu k_alpha data (Manuela, Jenny, Torsten)

Current source scans (DRSCS) (Alexander, Ulrich, Igor, Jola)


  • There are still boxes and our microscope lying around in the hutch and on the bench of the control room. I stacked the boxes and put them into a corner for the time being. Could you please pick them up again? (Ulrich)

6:00am : The glas capillary of the nozzle of the injector was found.

Only one wing does work at the moment. Detector gets stuck at stop86 and does not change state even when MFPGA is off.

9:00am: Touching cables and re-powering a couple of times helped. Now, both wings are back alive.

As capillary was found, now we search the water jet.

Status of the data

Jola and Igor tried to solve the problems we have/had with the data:

1. Change data order from ADADADAD... to AAAA...DDDD... to allow the DAQ to split the data into two dimensions
<number of frames>, <analog or digital>, <rows>, <cols>
(see here:

Result (Status 18:00):
There was data now in the second dimension (when ADAD... was used no data was contained) but it was not split between analog and digital but (as I saw it) arbitrary.

2. Trying to fix the problems with the data
(see here:

Still a lot of ASICs are only injected partially (similar as in the picture in the attachment, remark: this is a picture from the old data not the new).

I think it would be good if one of you who has more knowledge about the detector than me can maybe talk with them and help find the reason.

Investigated data:

  • Run: r0308
  • Module: 5
  • used current: itestc80

Sum of analog data per memory cell 

Strangely every second memory cell  for the analog data looks strange whereas for the digital we do not see this behavior:




Additionally on the individual frames not all pixels are injected correctly

Frame 0, cell 10

Frame 0, every other cell of the analog data (only 10 first one are displayed)

Pixel 2, 10:

Pixel 2, 10 correlated with trainid

Descibtion of the calculation: drscs investigation.pdf


Access to XFEL elog

I just learned how to get access to the XFEL elog. You have to do the following:

Access to the elog system

Go to:

Click on "Register as new user"

As account name choose your DESY account name
Enter your full name + email
password can be arbitrary because it will get overwritten by the one in LDAP (meaning your DESY password)

Click Save

Then Steffen (Hauf) will get a mail and once he has accepted it you can access the elog system with your DESY account.

Access to the AGIPD elog

To get access to the AGIPD specific elog, someone from XFEL has to give you permission (for me Jola added my account)

Today we tried to find out how the data is stored in the files at XFEL. These are our results:

Data is stored in the format:

  • file name:

    RAW-r<run number>-AGIPD<module number>-S<run part>.h5
  • data inside the file

    /INSTRUMENT/SPB_DET_AGIPD1M-1/DET/<module number>CH0:xtdf/image/data


  • run number: 4-digit number
  • module number: 2-digit number
  • run part: 5-digit number

This data is of the shape

<frame number>, <analog or digital>, <columns>, <rows>

for AGIPD that means: (<frame number>, 2, 512, 128)

XFEL expects the data coming out of the detector as blocks of analog and digital information: AAAAAAA... DDDDDDD

Currently we have interleaved analog and digital values: ADADADAD...

→ XFEL's DAQ is not able to split this into their format, meaning that the dimension destined for analog and digital is not working as expected

For the data we have already taken this means we have:

data[:, 0, :, :] contains all data (analog and digital interleaved)

data[:,1, :, :] does not contain anything meaningful

Code snippet to devide the data looks like this:

for c in range(cells//2):
	analog = d[2*c::cells, 0, ...]
	digital = d[2*c+1::cells, 0, ...]

Investigation of two modules

Module 3

Module 4

Details on generation of the plots: Find powder diffraction rings.pdf

Including the firmware in the repository

Currently we have one repository: "Calibration". This includes "qualitycontrol", "src_data", and "patterns". The developments of "patterns" and the (to be created) "firmware" are pretty independent from the others, should we create a separated repository for them?

Stash repository for calibration

I have just created a stash project called "AGIPD". The "fsds-users" group has privileges to read/and write so all of the FS-DS members should be able to do so. Please let me know If you cannot.

I have created a repository called "Calibration". If you follow the link you will find the instructions of how to deal with the repository.

New Module Setup

The new module setup will allow us to run tests in parallel to the multimodule setup. I have checked what do we need for the new module setup in the X-ray lab. Here is the shopping list and the status of each entry:

-Vacuum board: We have ~10 of the new vacuum boards (with the CML driver already implemented).

-Backplane, Analog boards (mother+daugher), FPGA board and digital carrier: we have them from previous module setups.

-Mechanic support: already in the lab.

-Transcievers and ethernet cables (1G and 10 G): already in the lab.

-Power supplies: There are enough Wiener power supplies (those in the rack) to run one module. Today enough power supplies to run a full quadrant will be taken from XFEL.

-Cables: We are looking for the set of cables used at APS (waiting for P. Goettlicher answer) for both LV and HV connections.

-Firmware: The card with a lable "20150604..." written with red ink should be used. It is around in the lab.

-Table: We just need to move the stuff of the multimodule into one table to have the other table free to mount the setup.

Let's get started

I think this space is a good tool to keep our calibration progresses documented. I have created a file list called "slides" to include the slides with plots, comments, summaries...regarding to some particular calibration issue. I deeply encourage you to upload as much materials as possible, I believe in the future it will become very efficient to check (or cross-check) information. It would be ideal to have all the code backed-up through STASH (another Atlassian tool) in such a way that we can also post the problems and/or features of the different versions of the code, but I guess we need a bit more time for it. Finally, having the versions of the working firmwares for the FPGA in the STASH would be great to avoid potential confusions in a stressed,busy, and close future.

PLEASE: comment and/or suggest and/or others! (smile)