Test Results of the Short Strip ASIC Prototype Module

General information

• Contact person: Marc Osherson
• Author list: full Tracker author list
• Reviewers: Mark Pesaresi (chair), Lea Caminada, Sarah Seif El Nasr Storey, Katja Klein (ex-officio)
• Target journal: JINST
• Status (April 2021): 3rd version of draft reviewed on 19th of April

First version of the draft

• First version of draft, as received on 14th of September 2020: pdf

Comments to the first version of the draft

• Comments by Katja, 3.10.2020: pdf
• Comments by Mark, 8.10.2020: pdf
• Comments by Lea, 9.10.2020: pdf
• Comments by Sarah, 9.10.2020: AnnotatedPdf, ListOfComments

Second version of the draft

• Second version of draft, as received on 16th of December 2020: pdf

Comments to the second version of the draft

• Comments by Lea, 6.1.2021: pdf
• Comments by Katja, 8.1.2021: pdf
• Comments by Sarah 18.1.2021: pdf
• Comments by Mark 19.1.2021: pdf

Author responses for second round of comments:

Lea's comments:

• section 1: Multiple comments
  • We've re-written the introduction, so most comments aren't directly applicable. We have however included more background on the current CMS Detector, the HL-LHC, the IT and OT, and the PS tracker (including 2S module)
• section 2.2: suggest to rephrase "center of the sensor"
  • The sentence has slightly evolved: The sensor is read out by two SSAs, with the boundary between the 120 channels connected to each chip located at the center of the sensor.
• section 2.3: Why and wrt what?
  • Prior to a full alignment of the system, it's difficult to be sure which tracks miss the DUT (and thus shouldn't be counted against an efficiency). Once the full alignment is done, we know exactly which tracks to keep or discard (this is what results in the paper use, but not what was used to while taking data). We've clarified this in the text.
• table 1: Add the uncertainty of the fitted parameters in Tab. 1
  • They're now included.
• section 4.2: Section 4.2, L109: "Newly rotated":
  • This a confusing way to say that the rotation is about the y-axis as defined after a rotation in gamma. However, the nominal value for gamma for the entire experiment was 0... so we will just drop this and say that alpha is the rotation around the y-axis.
• Section 4.2, L113: "Both are modeled as straight lines":
  • The track is modeled as a straight line, as is the central axis of each strip. The latter is probably obvious and to avoid confusion we re-stated this to just specify that the track is modeled as a straight line.
• figure 5: Normalized number of clusters
  • Fixed
• section 4.3: Why is this not the default setting? (compare L96)
  • This value of the threshold is just above the noise: where the hit efficiency is essentially 100% without significant effects from the noise itself. With hindsight we might have used the default setting, but we wanted to be absolutely sure any efficiency loss we saw was due to the timing, not the threshold.
• section 4.4: Is there any explanation for this?
  • The HIP thresholds cannot be trimmed, so this may explain it. We have added this information to the paper, but do not go as far as to state that this is the reason for the slight difference.

Mark's comments:

• Intro: This ref refers to the Tracker upgrade, while you start the sentence with the CMS upgrade. Consider adding more introductory sentences motivating the upgrade of the machine, CMS and eventually discuss the replacement of the Tracker.
  • The intro is re-written to hopefully introduce things more naturally. The correct refernce is now used.
• Intro: At least a reference and brief mention of the Inner Tracker is required (an Outer implies there must be an Inner!)
  • We cite it and mention it now.
• Intro: the other type of module (2S) should be explained for context
  • We now mention it explicitly and cite some papers that describe it.
• around line 19 etc (40MHz): i think you can expand on this - the motivation is not clear at all and deserves an intro (perhaps accompanying the first sentence in this para)
  • The 40 MHz number if not relevant in the re-written introdution
• Experimental setup intro: overall better than last draft but - can we be more specific about the measurement aims? what is purpose of TB? is this the first module/measurement of its kind?
  • We've added a sentence to preview the measurments shown in the paper.
• section 2.1: as i said in last draft - be careful here 1/4 MIP refers to nominal setting - see my other comment... (also MIP can mean many things - define in electrons as well)
  • We've corrected the mistake, 1/4 is the nominal detection setting as you noted. We've also converted it to electrons assuming 75e/um in silicon.
• section 2.1: overall better than last time but still a bit weak, repetitive and occasionally too close in phrasing to the SSA manual . (to repeat! myself again) i still think you should ensure the SSA designers are able to contribute and review this section, and indeed the paper given the results are relevant to them too. (and should be on the shortened internal author list in my opinion too). there is plenty more relevant detail that could be added about the operation of the ASIC, e.g. operational modes, configuration settings, etc.. i see no mention of offset tuning, power, noise, radiation hardness to name a few. the fact that the clustering logic is not described at all leaves the reader with many questions in the later sections.
  • We have tried to beef up this description without needlessly repeating information already in the SSA paper that we cite (this was the preference of the ASIC designers, who have now read and commented on the paper). We do add some description here though. One thing to note: these results do no use the SSA's clustering: we only read out the L1 hits and clustered ourselves offline. We have made a note of this later in the paper when the clustering is brough up (and where a description of the clustering is also laid out).
• section 2.1: this could really do with a dataflow diagram
  • We've added one provided by the chip designers.
• section 2.1: which chip ?
  • The MPA (in the PS module) and another SSA (in the 2xSSA module), that's been made clear in the text now.
• section 2.2: a picture is fine for showing the resulting module, but you definitely should add a diagrammatic figure of the module and its components/structure/connectivity
  • Unfortunately no serious diagram exists, so I've made a cartoonish one that I think nonetheless gets the point across?
• section 2.2: what about sensor biasing? operational settings? there is no mention of the DAQ whatsoever - how is this thing read out? this needs a section at least
  • We've added a section on the readout, as well as mentioned the sensor bias voltage (you may recognize the citation for the FPGA uTCA). For operational setting, since the non-standard operational modes of the SSA aren't brought up anywhere, we haven't specified.
• section 2.3: the strip planes measure one coordinate? or are composed of x and y sensors? what about the DUT - which orientation is it aligned with?
  • Indeed, each strip plane is un-segmented and alternates between x and y. We think this is clear in the paper so we haven't changed the description, but we have noted the (y) direction that the strips of the 2xSSA pointed.
• section 2.3: what frequency? make clear that the clock is asynchronous to the particle ToA. its still not obvious how the timing adjustment discussed in section 4.3 is done (im starting to guess this is done offline? if so make clear here what the telescope records in terms of track info e.g. time!)
  • 40 MHz. The phase of this clock w.r.t. the accelerator clock is constant (indeed the 40 MHz is derived from the beam clock). Hopefully the timing section is now clearler? (clock specifics added to the text)
• section 2.3: actually the OTSDAQ is not the whole DAQ but a part of the software right? this ignores the CAPTAN DAQ hardware for the telescope. however you make no reference to the DAQ for the DUT - how was this integrated? again you should expand here on details, talking to experts if necessary
  • We've added more information to the new DAQ section.
• section 2.3: ended prematurely?
  • Sorry about that. Full sentence now visible.
• section 2: a general point - i think it is not mentioned anywhere in the paper that only the full hit data is recorded/analysed in this BT, and the stubs are ignored or not recorded. this should be clarified somewhere (somwhere in section 2)
  • We now bring this up when we describe the data streams of the module.
• Section 3: this needs to be cleaned up and clarified - you talk about the Landau and reference the original paper, but my guess is you are using the approximation provided in the ROOT TMath libs - is this correct? if so you should say so - being specific about the routines you are making use of would go some way to clarifying non-standard terms like 'location and width parameters' which are specific to this routine. if you are looking for the underlying routine used in TMath it is https://www.sciencedirect.com/science/article/pii/0010465584900857 - however there is no mention of location and width parameters in here (this is ROOT-specific nomenclature). Most probable value is the term most people are familiar with, which "location" is a close approximation of.
  • We've tried to make the text readable to a non-ROOT user, switching to most probable value. We also point out that we use this computational model (thank you for the reference!)
• section 3: location? this is not a standard term
  • We're calling it "most probable valule", and then immediately defining it as \mu
• section 3: personally i would use symbols for location and width (the words mean nothing to the average reader)
  • We now define \mu and \sigma early and use those throughout.
• section 3: by addressing the above comments, i think this would help clarify why your "location" parameter is allowed to be a free parameter. if this were a proper geant simulation for example, the MPV would be a fixed number (based on Si thickness & particle energy etc.). If instead you clarify that you are using a computational function given by TMath to approximate the Landau for example then it makes sense that the parameters do not quite correspond to the underlying physical constants
  • We've made the change you suggest!
• section 3: the MPV for 120GeV protons in 240um of silicon is ~19k electrons so quite close to the fitted x0. you might want to comment or include this to back up the model and resulting fitted parameters
  • We've added a mention of this, as it does indeed build confidence in the simulation!
• section 3: better than the last draft, but i still think a diagram of the various effects simulated to aid the reader would be helpful and interesting. e.g. show the sensor cross section and highlight deltaS, fractions on each strip/gaussians. if not a diagram, then the mathematical models
  • Our attempts at diagrams are more confusing than anything else, but we have implemented equations with each part explained.
• section 3: "sharing" - still disagree with this so please tell me im wrong. shouldnt cross talk be an additive effect? its a capacitive coupling right?
  • It is a capacitive coupling (we specify that in the paper to make what we're talking about clearer). Maybe now it's clearer? No extra charge is created, it just moves from one strip to another, but it is a different effect than the diffusion.
• section 3: i assume you mean electrical noise - which includes sensor and analogue amplifier noise. please clarify in text
  • Clarified that it's the total noise from sensor and front end
• section 3: measured how?
  • We now describe this in the original description of the SSA.
• section 4.2: can you show gamma in a diagram - perhaps fig 4? which you should refer back to in this paragraph anyway
  • It's been added, and referenced.
• section 4.2: aligned? or determined precisely? rather than optimised
  • we went with "determined precisely".
• section 4.2: dont you mean closest cluster centroid? or do i misunderstand what you are doing here?
  • We do, and we've updated the paper to reflect this.
• section 4.2: the minimisation is performed once on each angle independently or for the entire system in one go. state how this is done.
  • It's done simultaneously for all angles since the parameters are "properties" of the module, not of the geometry. The paper is now explicit about this.
• Figure 5: normalized what?
  • Now it's "normalized number of clusters"
• section 4.2: does this mean you only minimise for a subset of the 6 parameters in this system? or are the results of the fit for parameters which are badly constrained ignored? state what is done
  • Yes, they are simply ignored. We've now stated as such.
• Figure 6: plot should be made larger (or combine with fig 5) - y axis can just be written as \Delta x, x axis need not say (telescope)
  • We made it bigger, but the final size will likely change depending on the journal formating preferences. We did not combine with Figure 5.
• section 4.3: I think you mean ' This can be achieved by adjusting either the trigger arrival time or the pointer to the pipeline location containing the buffered hits. If you dont mean this then i think there is some confusion as to what you are actually doing in this section (possibly because not enough info is given in section 2)
  • It does mean that. We've upated the paper to say exactly this.
• section 4.3: this paragraph is still confusing - i have made comments about this in the previous draft, but i wonder if the issue is that the method here is just not clear (to me at least). perhaps we could discuss this over mail or in a quick call
  • This paragraph has been removed completely. All it did was confuse every reviewer and it adds nothing relevant to the discussion.
• section 4.3: sub-optimal in terms of ? resolution? margin? what?
  • In terms of efficiency, as now noted in the paper.
• Figure 8: can we find a better shorthand? make a parameter and introduce it in the text (and caption)
  • We've defined and used a symbol for this and Figure 8 and in the text ($N_\mathrm{cl}^\mathrm{>1}/N_\mathrm{cl}$)
• Section 4.4: two threshold values... - thinking about this, might be be more convenient to label the two thresholds Lower and Upper or Standard and HIP? or whatever the SSA manual states? this would make talk of thresholds less ambiguous. this should be done early on in the paper. you also have a Q later on - how about simplifying and standardising on the nomenclature
  • We now introduce "standard" and "HIP" thresholds form the start, in section 2, and then stick with those names throught
• section 4.4: use new shorthand symbol
  • We've defined and used a symbol for this and Figure 8 and in the text ($N_\mathrm{cl}^\mathrm{>1}/N_\mathrm{cl}$)
• Figure 9: lets make a parameter for this (see fig 8)
  • We've defined and used a symbol for this and Figure 8 and in the text ($N_\mathrm{cl}^\mathrm{>1}/N_\mathrm{cl}$)
• Figure 9 caption: insert new symbol here to refer to new axis label
  • Done.
• Section 4.4: you introduce Q here - please do this in the text (perhaps even in an earlier section e.g. 4.1 or even before so you dont need to repeat yourself)
  • We now introduce (Q) as the measure of threshold in Section 2.
• Section 4.4: see comment above on labelling the thresholds in this paper consistently
  • We now introduce (Q) as the measure of threshold in Section 2.
• Sectin 4.5: how/where does the fitted width (14.7) come from?
  • The resolution is extracted from the data: it is a free parameter which floats simultaneously across all runs (with the effect of the angle taken care of by the 1/cos term in each fit). The resolution "at the DUT" is varying, so I'll add to the text that this value corresponds to the alpha = 0 case.
• Section 4.5: where is that stated? how does 8um correspond with 14.7 above?
  • Not sure where this came from, but I've confirmed that 14.7 is used, not 8. Fixed in paper as well.
• Section 4.5: even if you are not able to report on this, can you make some comments about analysis that was not performed here, but in my view are important tests to verify performance? e.g. noise performance? trigger path verification? verification of chip-2-chip intercommunication (for the clusters) and so on... seems relevant for a first paper on this ASIC on a module in a beam (that i know of)
  • We are hesitant to make comments on anything outside the scope of the paper, especially if we did not make a formal measurement. Some mentions have been added (throught the paper where relevant, rather than all in this section): the noise in the sensor is shown along with the S-Curves, and a mention of how it was obtained is made in the text. The chip-2-chip is briefly brought up (and it's noted that we dont' do anything with it). I'm not sure what you mean by trigger-path verification: the chips were triggered for all the data taken here, so maybe that is sufficient verification? There are obviously many other measurement we could have made, but we prefer not to include a list of missing items.
• Section 5: conclusions/discussion still short - i repeat - needs some work as reads as slightly irrelevant (which it shouldnt be, given that this is an important study!!). summarise the main results and why the specs (which specs?) are met. what comes next in terms of the PS module prototyping? the SSA verification (beam/SEU tests)? MPA? stub path verification? module assembly? this could even be a separate section.... this should be the first published result of the SSA in a beam right? mention this! the parameterised simulation model seems pretty robust from my perspective. discuss this! a lot of hard work went into this, not just your results in the paper, but also in the design of the chip, the hardware, the DAQ and so on, so try to do this justice for CMS
  • The section has been significantly expanded, including withh some of these items. Again (see above), we prefer not to comment on anything we don't explicitly have data for (this includes in a sense "next steps" since we don't want to outline a plan for the OT that may not be realized: for example the MPA went throughh a similar test beam, but the results were not published).
• Section 5: which specifications? only a subset it seems - see my comment above
  • We didn't find "specs" to direcly compare to, but on the suggestion of Sarah and Katja we've used our simulation (and the great agreement with the data) to make the statement that the SSAs behaved as expected. We've also slightly expanded this sentence to note the efforts in module assembly and software which underpin these measurements. We have removed the word "specification" and replaced it with "expectation".

Katja's comments:

• abstract: Still very short. Add something like: The prototype module has been characterized at the Fermilab Test Beam Facility using a 120 GeV proton beam.
  • Much longer abstract now written. Please let us know if it is what you had in mind!
• section 1:
  • This section has been significantly re-written, so individual comments don't line up anymore, but we hope the end result is better?
• OK, we've added the usual CAD drawing.
• Figure 1 caption: the modules are composed of many items, not just of the ASICs. Rephrase.
  • The caption has changed a bit so this isn't applicable anymore.
• Introduce the CMS coordinate system in a footnote. You need r, z, eta.
  • We've added this, though maybe it's unecessary?
• Figure 2 caption: seeded?
  • Fixed.
• Move figures to very bottom of the page.
  • We haven't implemented this now, as the final version for the journal will likely have a different format.
• Section 2: I think "timing studies" is quite sloppy. Can you find a better wording?
  • Studies of timing, efficiency and resoltion?
• Section 2.1: I am not convinced by the structure. I see two problems: 1) the SSA architecture and readout is described partly in the intro, partly in 2.1, with some repetitions. 2) Section 2.1 described the general behaviour of the SSA and does not fit well into the Section 2 = "Experimental setup". n order to fix both problems, a new section 2 "The Short Strip ASIC" could be introduced, where you describe the generical behaviour/architecture of the chip.
  • We agree with this structural change: The SSA now has its own section (the new Seciton 2)
• section 2.1: the "path" is not "consisting" of hits, please rephrase this
  • Changed to "which carries".
• section 2.3: along what? I guess not along all 3 axes?
  • Actually it can rotate around x and y, and also move along x and y: we've made this explicit in the text.
• section 2.3: Sorry, but what or who is Monticelli? This needs to be rephrased or explained.
  • Monicelli is a software package. We now specifically say this and include a citation.
• section 2.3: Something seems to be missing here. Differ from what? The offline efficiency, I guess?
  • Yes, the offline efficiency. The text is fixed now.
• Figrue 4: Can the angle gamma also be shown in this sketch?
  • Yes, it's been added.
• Figure 4 caption:
  • Implemented both comments.
• Section 3: see comment to Tab. 1
  • Here and in the text we're using most probable value, though we immediately define it as \mu and use thhe symbol for legibility.
• Section 4.1: make clear around which axis (can refer to Fig. 4 now).
  • Whole paragraph slightly reshaped, but should be clear now.
• Figure 5: Normalized number of clusters
  • Fixed
• Figure 5: angle
  • Now says Angle \alpha, is that ok?
• section 4.2: Here I realize that you never said how the module is oriented in the beam, i.e. in which direction the strips are actually pointing (x or y). This should be added in Section 2.3.
  • This information is now added.
• section 4.3: what is meant by "shape of the timing scan"? The scan is a method, it cannot have a shape. Please rephrase.
  • We have removed this paragraph completely. It doesn't add any useful information relevant to the results presented and confused everybody who read it.
• section 4.3: I do not understand what you mean with "raw distribution" or "raw timing distribution". Please clarify.
  • We have removed this paragraph completely. It doesn't add any useful information relevant to the results presented and confused everybody who read it.
• section 4.3: I am still confused by this paragraph.
  • We have removed this paragraph completely. It doens't add any useful information relevant to the results presented and confused everybody who read it.
• Figure 7: Can you call this "Trigger delay" or something else that is more specific?
  • Fixed
• Figure 7 caption: for (I am sorry, my earlier comment makes no sense to me now)
  • Fixed
• Figure 8: I think this should be "clusters" and in fact "Number of clusters". I understand that this will make it too long. Maybe it would be better to introduce variables N_clusters and N_clusters (W > 1) so that the label can be consise and correct.
  • We've defined and used a symbol for this and Figure 9 and in the text ($N_\mathrm{cl}^\mathrm{>1}/N_\mathrm{cl}$)
• Section 4.4: thresholds - I found it confusing that you talk about 2 thresholds here. Maybe it is clearer to just say "the threshold" here, and then introduce the other study later separately (as you do)?
  • We now introduce "standard" and "HIP" thresholds form the start, in section 2, and then stick with those names throught
• Figure 9: See earlier comment.
  • We've defined and used a symbol for this and Figure 8 and in the text ($N_\mathrm{cl}^\mathrm{>1}/N_\mathrm{cl}$)
• Section 4.5: I am confused - where actually do the 14.7 stem from now? And why do you write sigma_tele = 14.7m in all plots, irrespective of alpha?
  • The resolution is extracted from the data: it is a free parameter which floats simultaneously across all runs (with the effect of the angle taken care of by the 1/cos term in each fit). The resolution "at the DUT" is varying, so I'll add to the text that this value corresponds to the alpha = 0 case.
• Figure 11: Number of events
  • Fixed.
• Figure 12 caption: This is not well phrased, and confusing. I think what you mean is that at 0m there is the border between two implants, which have their centers at -50m and +50m. Please rephrase this.
  • This now reads: The border between two strips is at 0μm, and the strip implantsare centered at -50μm and 50μm.
• Section 5: In fact, you have not discussed the specifications. So you are just claiming that it is consistent with specifications, you are not proving it. Indeed the paper would profit from mentioning the specs, which is in fact often asked by JINST reviewers. Otherwise, if you cannot do so, it would be better to just say here what was measured and what was the result (but of course then the question comes up: is it good enough?)
  • We do not have “specs” necessarily (other than that the module should be fully efficienct, which we now state clearly in the conclusion). I’m not sure what else we can mention here other than the good agreement with simulation (which we also do now in the conclusion). We've changed the word "specifications" to "expectations".

Sarah's Comments:

Section 1:

• OC : possibly also one of the rendered images of the PS module design? Could you please include an image of what the PS module will look like?
  • We've added one.
• I think that it would be worthwhile to strengthen the introduction by including a more complete description of the tracker upgrade and the pT module concept.
  • We've added more information and re-arranged the introdcution. Please let us know if this is better.
• Since this is the introduction to your paper I think its worthwhile to spend some time introducing the reader to the concepts of the upgrade that we ‘take for granted’ in the upgrade community before diving into the details of the PS module. This draft is already a marked improvement on the original in this respect, but I think it can still be further improved. The description of the two data paths in the PS module is much better than in the original draft, but I think it can still be further clarified. Perhaps by simply everything that the SSA does first (hit detection, cluster formation, cluster buffering) , then the role of the MPA ( hit detection, cluster formation, cluster buffering, stub formation, L1 data packet formation). More in-depth technical details about the SSA (two thresholds, buffer depths, max trigger rates, lateral communication, etc.) can then be reserved for a separate section on the SSA.
  • We've done as you suggest: the details of the SSA get their own section and the introduction is more about the PS module and OT upgrade in general.
• OC, L4 : Please be a bit more precise with regards to how this compares to the current LHC (xx fluence, xx current occupancy) Still not precise enough, five-fold with respect to what? Either quote the absolute numbers for the current tracker or the specs for the upgrade
  • Done, we quote the final parameters for the HL-LHC.
• L9 : ‘two types of modules ‘ - you only describe one in the text, and then mention 2S modules in the figure caption. There is no need to go into great detail about the 2S modules, but perhaps re-writing the first couple of sentences to be a bit more ‘generic OT’ and replace part of Figure 2. with a similar picture for a 2S module , and first describing the pT module concept. requirements for the tracker before going into the details of the PS module that are relevant for the paper could strengthen the introduction.
  • We think the same figure is appropriate for the 2S as well as the PS, so we didn't change it, but we make clear in the caption now that it applies to both chips.
• Figure 1 : ‘related 2S modules’ - related to what? Perhaps also reference one of the 2S module beam test papers/notes here.
  • We're not sure which reference you have in mind? Right now we quote [5] and [6] when the CBC is introduced.

Section 2 :

• Perhaps moving the description of the DUT ( SSA description, 2xSSA mini-module etc.) could be moved to a separate section?
  • We've re-orgniazed this to cover the SSA on its own first, then the 2xSSA module, then the beam itself.
• I also realized that nowhere in the paper is there a mention of a test with beam data that verifies the lateral communication between the 2SSAs. I assume that’s why a mini-module with 2SSAs rather than a single SSA was chosen for the beam test. If this wasn’t addressed in the data analyzed for this paper then I think its still worth mentioning something along the lines ‘studies of the efficiency of the lateral communication were either previously shown here (x)’ or ‘studies of the efficiency of the lateral communication will not be addressed here’
  • It's true we don't do anything with the stubs or the lateral communication. We now mention that in the paper, though we do note that we confirmed that the lateral communication works (and that it was rigged to run between the two chips). I think what we have now does it justice?
• L29 : ‘controlled beam’ - what does ‘controlled’ refer to here?
  • Just meant to establish that the beam parameters are under our control, but maybe this is obvious since we specify its parameters further in the section. Will remove.
• L32 : no reference is made to the second threshold after it is first mentioned. Please provide details on that if you would like to refer to it here.
  • We now explicitly name them and can refer to them by name. Hopefully that aleviates the confusion.
• L37 OC : Please be more precise about what the size of the signal from a quarter of a MIP in a fully depleted strip sensor of a PS module. (If you know what the value (in electrons or fC) is expected to be for a fully depleted PS strip sensor then I would suggest including it here.)
  • Done!
• L37 : I think the manual states that the 1/4 MIP is the nominal and not the minimum threshold.
  • Thank you! Fixed!
• L38 : ‘.are latched with an edge sensitive circuit …’ - it took me a while to figure out that ‘latched’ here refers only to the digitization and not the sampling of the comparator output. I know its a minor detail but could you please add another sentence describing the sampling in a following sentence before mentioning the fine adjustment of the sampling phase? I think that could help guide the reader.
  • We've slightly simplified this sentence to make it clear that we are talking about the digitized signal (both of them since we now distinguish the HIP and standard thresholds):

    "Both signals are digitized with an edge sensitive circuit sampled at 40 MHz. In order to maximize the hit detection efficiency, the sampling clock phase is adjustable in steps of 200 ps across the full 25 ns bunch crossing period."
    Is this clear enough now? We no longer use the word "latched" as it obfuscates the meaning of the sentence.

• L42 : ‘the second chip’ - perhaps better to be explicit and say MPA?
  • We agree, fixed.
• L63 : ‘geometry’ - configuration? L68 : ‘readout using OTSDAQ’ - I think technically the DUT is readout by our upgrade firmware + software and OTSDAQ is only used as a final wrapper around the sw that actually communicates with our readout firmware. There is no need to go into the technical details of the uDTC + Ph2ACF, but it would suffice to refer to one of the presentations/theses written on the topic.
  • Actually we have added a bit more information on the readout so we’ll go into the details a bit more.
• L69 : ‘In particular the online..’ - I don’t understand the context of the sentence with respect to the rest of the paragraph…
  • The whole sentence has been re-worked. Hopefully now it makes sense?

Section 3 :

• The explicit reference in the text to the usage of data collected at various angles and thresholds to extract the model parameters has been removed, however Figure.9 still shows that data collected at different angles was used. Can you please be explicit in the text as to why you chose to do that? And how the results of the model parameter extraction across the different data sets was performed?
  • The text now explicitly notes the multiple angles are fit simultaneously.
• OC : I still think that some kind of mathematical description of the model would be much easier to follow than the current written description. I see that some of the other referees have also made similar comments on the first draft so please consider adding this. (I would find it very helpful if you could add to this section an illustration which shows two strips , the different mechanisms by which charge is collected by the strips, and a few equations that describe how the charge collected by a given strip is expressed in the model. I know its all in the text, but I personally find it easier to follow the text when there is more information provided. Also, it would be nice if you could show an example output of the simulation for what you expect the nominal parameters to be based on the detector that you are studying. This already prepares the reader for the type of plots you collect at the beam test and I thin can really help make the discussion in the paper much easier to follow.)
  • We've added a math equation for the actual charge collected in each strip. We don't have an "example output" as you suggest, we're not sure what that would look like exactly. At any rate, hopefully things are clearer now (the text has also been improved since the previous draft)?
• OC L73 : At this point in the paragraph I still don’t know which data.. by the end of the paragraph I know that its the cluster size and the efficiency but I would personally rather know at the start. (Which data?)
  • Fixed.
• OC L87 : How is the noise of 830 electrons calculated .. in the first draft of the paper it was 930 electrons and now it is 830 .. why the change? (How is the noise of the sensor determined?)
  • Sorry for the mistake, this was due to a miscommunciaton between contributors but has been fixed. The noise wass 830. We now specify that this measurement was done just before receiving beam (after installation). When the SSA is introduced we now mention how the internal biases are calibrated so that we can calibrate the threshold to electron units.

Section 4 :

• OC L104 : Please define efficiency here. (Please explain here how you will be defining the efficiency in the analysis.)
  • We moved any mention of efficiency from this section since it’s not actually used until the timing studies section. There we explicitly define it before using it.
• A significant amount of time is spent in the section on the alignment explaining to the reader how useless most of these alignment parameters actually are .. but then .. nothing much is mentioned/shown regarding the parameters that can be constrained by minimizing the residual which feels a little strange. Perhaps something can be added that helps balance this out a little?
  • We’re not sure what there is to say: all we do is align our computational model to the actual geometry. We’ve added a sentence about what we do with the unconstrained angles (which is ignore them).
• I think the second paragraph in section 4.3 is still a little vague.
  • We removed it completely, as it didn't add anything valuable and just confused anybody who read it.
• Do you have any explanation for the asymmetry of the shape? Was any attempt made to fit this with a model? Or compare it to a simulation?
  • I don't think we do. Our other simulation doesn't take into account the rise time of the signal, so it would not be sensitive to this. For now we have no comment to make on it in the text.
• L108 : Please also define the rotation angle gamma in Figure.4
  • Added!
• L110 : Please refer to Figure.4 where these angles have now been defined.
  • Done!
• L119 : ‘rotation around z’ - can you please indicate which of the three angles mentioned in Figure.4 this refers to.
  • Done!
• L134 : I agree that Figure.9 shows that the efficiency is high at the threshold mentioned but it doesn’t give any direct indication about the noise. It might be useful to show a single plot, rather than refer to a figure that is used later, that overlays the noise-hit occupancy and hitoccupancy vs. threshold for the module at this point in the text.
  • I think the noise is properly shown on that figure (at least for the purpose of validating this choice of 4800 e)? We think it’s better to use one figure rather than put the same information twice? We could move that figure earlier so the reader doesns’t need to “skip ahead”? For now we’ve left it as it was.
• L135 : ‘almost 100%’ - please be more precise as to the exact value at which you find the efficiency plateau.
  • We specify now that it's 99.75%
• OC L142 : An additional sentence explaining why it is important to maximize the fraction of events with a cluster size greater than one would be good.

  • Such clusters become increasingly likely as the incident angle of the beam increases and charge deposited by the protons is more likely to be recovered across multiple strips.

• L146 : ‘DOT’ or ‘DUT’?
  • DUT! Sorry!
• L146 : if you have the data collected from the online measurements of efficiency here then please include a plot that shows them here.
  • We do not have such a plot, and prefer only to show results properly reconstructed after a full alignment.
• Also, can you be a bit more explicit about how tracks near the edges of the sensors were not properly taken into account? And explain why that affects the efficiency?
  • This online calculation, which uses a less precise geometric alignment of the DUT, did not reject tracks just outside the actual sensor boundary from being considered when computing the efficiency.
• L150 : Please quantify rare. And .. do you know what the source of these ‘extra’ clusters in the collected data is? If so, please include an explanation for them.
  • We've changed this sentence to "Clusters not associated with a track are discarded." We don't want to quote a number since it varies dependong on the threshold (and geometry).
• OC L168 : Perhaps this is obvious, but do you understand why the efficiency is lower for the second threshold?
  • Unfortunately no, not exactly. Ee aren’t sure why it’s lower. These thresholds are untrimmed so it may have to do with that? We aren’t sure what (or if) to comment.
• Figure 10 : Was the scan of the secondary threshold not performed for the same set of thresholds as the primary threshold? Its hard to tell from the plot whether there are points at values below 15ke or not.
  • There are no points below 15ke.
• Also, can you please mention the primary threshold used for those scans? What value was it fixed at?
  • The primary threshold is not fixed to 30 DAC units below (except for one point where it is 25, not sure why). We prefer not to mention this since they aren’t supposed to depend on each other and we don’t want to imply they do.
• L175 : 14.7 um is the width of a fit to what?
  • The resolution is extracted from the data: it is a free parameter which floats simultaneously across all runs (with the effect of the angle taken care of by the 1/cos term in each fit). The resolution "at the DUT" is varying, so I'll add to the text that this value corresponds to the alpha = 0 case.
• Figure 9 : I personally still find the title of the y-axis very confusing. Not all the data points there describe the same thing, and its a busy plot.
  • It is a rather busy plot, but we’re not sure what else to label the axes. The left axis is definitely the efficiency since it’s events / triggers. The right axis is the noise occupancy (in different units). Is there a better way to represent these?

Section 5 :

• OC This is a bit.. terse as a conclusion. Perhaps include a table that shows the properties of the DUT studied with the data collected at the test beam and compare those with the specs?
  • Indeed: we have significantly expanded it. We don't have a table, as there aren't really stated "specs" to compare to for most measurements, however, we do compare to the simulation to drive home the point that the SSAs and sensor are behaving like they are supposed to.
• Also - given that you spend quite some time describing the simulation used to analyze the data collected a sentence or two about its use would also be useful.
  • Added.

Third version of the draft

• Third version of draft, as received on 19th of April 2021: pdf

KatjaKlein - 2021-04-23