Conceptual architecture of the detector infrastructure for WST

A. Meoli; A. R\"ude; E. George; M. Richerzhagen; M. Seidel; O. Iwert; O. Squalli; S. L\'ev\^eque

REVIEW 3 major objections 4 minor 14 references

Conceptual architecture of the detector infrastructure for WST

T0 review · 3 major / 4 minor · reviewed 2026-08-05 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper argues that the Wide-field Spectroscopic Telescope's ~750 detectors can be operated through a two-level distributed readout, with a single Cat6A cable per detector carrying data, timing, and power.

desk verdict A well-scoped, internally consistent concept paper for WST detector readout; the feasibility envelope rests on an explicitly optimistic white-noise model, so treat the numeric sizing as conditionally valid until the Pyxel assessment lands. read the letter →

arxiv 2608.00734 v1 pith:TRWMPMFW submitted 2026-08-01 astro-ph.IM

A. Meoli , O. Iwert , E. George , O. Squalli , M. Richerzhagen , A. Rüde , M. Seidel , S. Lévêque This is my paper · ORCID

classification astro-ph.IM

keywords WSTdetectorinfrastructuredistributedcontrollerup-the-rampreadoutCMOSdetectorsPoweroverEthernetreadnoisespectroscopictelescopeinstrumentation

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper is a conceptual sizing study for the detector control system of the proposed 12 m Wide-field Spectroscopic Telescope (WST), which would need on the order of 750 detectors across three instruments. At that scale, a centralized controller per detector becomes impractical, so the authors argue for a distributed two-level readout: a minimal warm electronics module placed at each detector, and networked aggregator shelves per instrument. A single Cat6A cable per detector carries the pixel stream, the timing signal, and electrical power, with Power-over-Ethernet Type 3 for 6k detectors and Type 4 for 12k detectors. The sizing—number of non-destructive up-the-ramp samples, frame cadence, raw bandwidth, compute load, and power—is derived from the multiply-sampled read-noise formula, and the target 3–5 e⁻ CMOS regime fits comfortably under a 1 frame/s ceiling with a 1 GbE link (6k) or 2.5 GbE (12k). The authors state clearly that this envelope is deliberately optimistic because real CMOS noise has 1/f and correlated components that do not average down as sqrt(12/M), so the figures are lower bounds to be consolidated by a planned end-to-end detector simulation.

What carries the argument

The two-level distributed architecture: (1) a minimal warm proximity module per detector that serializes, timestamps, buffers, and packetizes the pixel stream onto one Ethernet link, and (2) an xTCA aggregator shelf per instrument that terminates up to 32 links and performs the first reduction. The sizing machinery is the multiply-sampled read-noise relation sigma(Q) ≈ sigma_read sqrt(12/M), which fixes the minimum number of up-the-ramp samples M and therefore the required cadence, bandwidth, and link/power classes. The continuous-streaming mechanism—each buffered frame spread over the whole inter-read interval instead of being burst out—is what removes switch congestion, makes transport los

What would settle it

Take a representative scientific CMOS sensor and measure its noise power spectrum over a 900 s up-the-ramp sequence. If the fitted-slope variance stops decreasing according to sqrt(12/M) once M exceeds the ramp duration divided by the 1/f corner time, the Table 1 Mmin values are too low; recomputing cadence and bandwidth with the measured correlated noise would settle whether the 1 fps ceiling, 2.5/10 GbE choices, and PoE classes still hold.

Watch

Extended reading notes

Core claim

The central claim is that WST's detector system, roughly 750 detectors, exceeds the practical limit of a centralized controller requiring one 2U unit per detector, and can instead be served by two levels: a minimal warm proximity module per detector that digitizes, timestamps, buffers, and packetizes pixels, and networked xTCA aggregator shelves per instrument that terminate up to 32 links and run the first reduction. The paper derives the envelope from the multiply-sampled up-the-ramp formula sigma(Q) ≈ sigma_read sqrt(12/M): to reach an effective read noise below 1 e⁻ in a 15-minute sub-exposure, a 3 e⁻ single-read sensor needs about 106 samples (0.12 fps), 5 e⁻ needs 298 (0.33 fps), 10 e⁻

Load-bearing premise

Everything is sized on the premise that read noise is white and uncorrelated sample to sample, so M non-destructive reads reduce the integrated noise as sqrt(12/M); if 1/f or correlated row noise dominates, the required M and cadence grow and can break the 1 frame/s ceiling, the link speeds, and the PoE class sizing.

Editorial extensions

If this is right

A centralized controller with one 2U unit per detector becomes impractical at ~750 detectors; the distributed design replaces per-detector controllers with commodity Ethernet and rack-scale aggregators.
The 6k scenario (IFS and MOS-LR) can proceed with 1 GbE links and PoE Type 3, while the 12k detector and its FPGA choice can be deferred to MOS-HR maturity because only the interfaces between the two levels are frozen.
Streaming each up-the-ramp sample continuously over the inter-read interval removes simultaneous readout bursts, reducing peak aggregate traffic by roughly a factor of 5–14 and enabling lossless retransmission at no extra hardware cost.
Running slope fitting and cosmic-ray rejection as O(1) per-pixel state at the edge keeps compute one to two orders of magnitude below platform capability and keeps archived data near the few PB/year target.
If correlated or 1/f noise dominates, the required M and cadence increase; the 10 e⁻ and 15 e⁻ rows of Table 1 already exceed the 1 fps ceiling, so the paper's envelope is a lower bound, not a closed detector requirement.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Beyond the paper: the clean separation between proximity module and aggregator suggests the cable plant and shelves could outlive the first sensor generation—swapping only the detector module would adapt the same infrastructure to a different CMOS device within the link-rate and PoE-class constraints.
Beyond the paper: a direct test of the white-noise caveat would be to measure a sensor's fitted-slope variance as a function of M; once the ramp exceeds the 1/f corner time, the variance stops following sqrt(12/M), and the remaining link margin determines how much of the proposed 5× headroom is real.
Beyond the paper: the per-instrument partitioning means spare aggregator capacity cannot be pooled facility-wide, so an instrument whose noise forces higher cadence would need its own oversized processing rather than borrowing from a quieter instrument.
Beyond the paper: the same single-cable, PoE-fed, warm-module pattern could generalize to other multi-detector survey instruments, making the architecture a reusable template for detector-fleet control rather than a WST-specific solution.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The one thing you need to know: this is a solid, honestly-scoped conceptual design paper, but the whole sizing exercise hinges on an assumption the authors themselves call optimistic. If real CMOS 1/f noise breaks the √(12/M) scaling, all the link speeds, PoE classes, and aggregator counts shift. The paper says this plainly and defers to a planned Pyxel simulation, so treat it as a conditional architecture study, not a closed feasibility proof.

What is actually new: the WST-specific sizing itself — the M values, cadence, per-detector bandwidth, PoE classes, and aggregator counts derived from the Garnett & Forrest formula and the stated envelope. The arithmetic checks out; I re-derived the Mmin values in Table 1 and they match. The bandwidth and power tables are internally consistent. The continuous UTR streaming idea to remove simultaneous-readout bursts is well-motivated and the single-cable data/timing/power concept is clean. The paper is also unusually clear about what is a concept-stage estimate versus a firm requirement. That honesty is real and earns credit.

The soft spot is load-bearing: the entire infrastructure is sized on the white-noise UTR model. The paper itself lists the breaking mechanisms — 1/f and low-frequency noise, correlated row/common-mode noise, dark-current shot noise, image lag — and notes that real CMOS will not behave this way. If correlated noise keeps the effective read noise above 1 e− at M=900 (the 1 fps ceiling), then the 6k and 12k scenarios cannot be supported on the stated Cat6A+PoE+2.5/10 GbE links. The paper knows this and defers to Pyxel, which is the right next step. That makes the architecture conditional, not wrong. It's an unresolved dependency, and it's out in the open. For a conceptual design paper at this stage, that's acceptable, but readers should not think the envelopes are settled. Minor production issues: duplicate Figure 1 captions and a repeated paragraph in Section 5.2; these don't affect content.

Who this is for: the WST consortium, detector-controller engineers, and anyone planning readout for a facility with hundreds of detectors. It's not a fundamental science advance, but it is a carefully quantified engineering reference with a clear critical path. I'd send it to peer review for an instrumentation venue. The conditional caveat is explicit, and the appropriate ask is to require the Pyxel results in revision so the sizing can be re-benchmarked against realistic correlated noise. That would turn a conditional architecture into one you can actually plan against.

Referee Report

3 major / 4 minor

Summary. The paper presents a conceptual, distributed detector-controller architecture for the Wide-field Spectroscopic Telescope (WST), in which each detector is served by a minimal warm proximity module and groups of modules are aggregated by xTCA-based edge nodes. The same Cat6A Ethernet cable carries packetized data, PTP timing, and PoE power. The infrastructure is sized from the Garnett & Forrest up-the-ramp (UTR) read-noise formula: for a 15-minute sub-exposure and a target integrated read noise below 1 e-, the required number of non-destructive reads M and hence the raw per-detector bandwidth, link rate, PoE class, aggregator count, and edge-compute throughput are derived for 6k and 12k detector scenarios. The paper explicitly labels the white-noise assumption as deliberately optimistic, lists the mechanisms that break it, and defers a quantitative noise assessment to planned Pyxel simulations.

Significance. If the assumed noise envelope holds, the paper provides a credible and internally consistent first-order architecture for a detector infrastructure at an unprecedented scale. Its strengths are the transparent use of an external published noise formula, explicit order-of-magnitude budgets, the integration of power, timing, and data on one cable, and a clear separation between transport and processing layers. The paper also connects the design to the facility's sustainability goals and to available standards (IEEE 802.3bt, PTPv2, xTCA). The contribution is conceptual rather than final, and the authors are honest about the conditional nature of the numbers; nevertheless, the central feasibility envelope is monotone in the UTR sampling requirement, so the white-noise assumption is a load-bearing dependency that needs more quantitative treatment before the architecture can be considered closed.

major comments (3)

[Section 2, Eq. (1) and Table 1] The entire sizing (M, cadence, per-detector bandwidth, link class, PoE class, aggregator throughput) scales with the Garnett & Forrest white-noise formula. The paper itself acknowledges that real CMOS noise (1/f, correlated row/common-mode, dark current, image lag) breaks this scaling, but it provides no sensitivity analysis. Since the 1 fps ceiling and the 2.5/10 GbE choices are monotone in M, a correlated-noise floor that raises the required M from, say, 298 to above 900 would move the nominal 5 e- scenario outside the stated envelope. The planned Pyxel study is the right next step, but the present paper should either present the architecture as explicitly conditional on a specified maximum M, or include a parametric sensitivity table showing how Mmin and the required cadence vary with a noise-floor parameter. This is not a request for new simulations, but for making the dependency exp
[Section 4, power budgets and PoE class] The PoE Type 3/Type 4 assignment rests on the per-module power budgets of 20 W and 45 W, described only as concept-stage allocations. No margin for cable resistance, connector losses, or PSE-to-PD efficiency is discussed, and no reference is made to the maximum powered cable length under IEEE 802.3bt at Cat6A with data transmission. Since PoE class selection is a stated outcome of the paper, the power budget should at least include a standard derating or a clear statement that the quoted budgets are PD-side values and that the PSE budgets include loss. Without this, the reader cannot verify that the two classes indeed bracket the scenarios.
[Section 5.1, continuous streaming claim] The claim that buffering each frame in DDR-SDRAM and spreading transmission over the inter-read interval 'removes congestion by construction' presupposes that the buffer is large enough to hold a full frame at the highest format (for a 12k detector, of order 288 MB at 16-bit). The proximity module is described as 'minimal' but no DDR capacity is given. A short sentence quantifying the required buffer per format and confirming that the module's DDR-DRAM meets it would close this gap; otherwise the continuous-streaming guarantee is not established for the 12k tier.

minor comments (4)

[Figures] Two different figures are both numbered 'Figure 1': the cadence plot in Section 2 and the architecture diagram in Section 3. Renumber the second figure and update all references.
[Section 2, text near Table 2] The sentence 'the link approaches saturation at the upper end of the operating range' is imprecise: Table 2 gives 800 Mbit/s on a 1 GbE link for the 12k, 5 e- nominal case, which is 80% utilization, not saturation. Reword to 'reaches about 80% utilization without margin'.
[Section 3, first paragraph] Typo: 'approximately 2 height-unit 19” device unit per detector' should read 'approximately one 2 height-unit 19" device unit per detector'.
[Section 5.2, FLOP/byte discussion] The arithmetic intensity is stated as '~10 FLOP/byte' but the two components are 4 and 6 FLOP/byte, giving a sum of 10. Consider clarifying that the kernels are not mutually exclusive or that the 10 is a combined figure, to avoid confusion.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: infrastructure sizing follows the external Garnett & Forrest formula and IEEE PoE/Ethernet standards; the self-citation to [3] is a design starting point, not a derived result.

full rationale

This is a forward conceptual sizing exercise, not a derivation that re-imports its own conclusion. Table 1's M_min values are obtained by inverting the published Garnett & Forrest expression sigma^2(Q) = sigma_read^2 * 12(M-1)/(M(M+1)) with explicitly stated single-read RON values; no parameter is fitted to the target output and then relabeled a prediction. Table 2 bandwidths, the 1 fps ceiling, the 2.5/10 GbE link choices, and the PoE Type 3/Type 4 assignments follow by arithmetic from detector populations, pixel counts, cadence, and the IEEE 802.3bt class limits. The only same-author citation, Richerzhagen et al. [3], is used as a prior trade-space survey and as the source of the distributed-controller concept and a per-module power estimate; it does not supply the load-bearing feasibility numbers, which come from the independent Garnett & Forrest formula and external standards. The paper repeatedly and explicitly flags its white-noise UTR assumption as 'deliberately optimistic' and lists the correlated-noise mechanisms (1/f, row common-mode, dark current, image lag) that would break it, deferring to a Pyxel end-to-end simulation as the deciding check. This is an honest unresolved dependency of the design envelope, not a circular step: no equation or conclusion in the paper is equivalent to its inputs by construction.

Assumptions & free parameters 4 free parameters · 5 assumptions · 0 invented entities

The paper's sizing rests on chosen envelopes (detector population, cadence ceiling, power budgets) and an explicitly optimistic white-noise model. These are clearly stated concept-stage assumptions, not fitted parameters. No new physical entities are introduced.

free parameters (4)

Single-read noise scenarios = 3, 5, 10, 15 e-
Chosen as representative CMOS read-noise values for sizing; the paper spans a range rather than fitting to measured data.
Architectural frame-rate ceiling = 1 fps
Hand-set ceiling for the feasibility envelope; a class needing higher cadence is explicitly excluded.
Per-module power budgets = 20 W (6k), 45 W (12k)
Concept-stage allocations for the proximity module, determining the PoE class selection; not based on measured hardware.
Detector population envelope = ~750 facility-wide, ~400 worst-case instrument
Order-of-magnitude inputs from the WST instrument trade-off; the sizing uses the worst-case instrument.

assumptions (5)

standard math Garnett & Forrest formula for multiply sampled read noise
Used as the external basis for computing effective read noise as a function of M (Eq. 1).
domain assumption Read noise is white and uncorrelated between samples
The UTR averaging gain relies on this; the paper explicitly states it is optimistic and that real sensors violate it.
domain assumption Ethernet and PoE standards behave as specified
Assumes 1/2.5/10 GbE and IEEE 802.3bt Type 3/4 power delivery over Cat6A.
domain assumption Warm electronics near the detector with commercial components
Assumes digitizing at the detector and staying warm avoids the unavailability of cold-rated components.
domain assumption Detector formats are 6k (6144x6144) and 12k (12288x12288)
The bandwidth and power numbers scale directly with these assumed pixel counts.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Conceptual architecture of the detector infrastructure for WST." pith.science (2026). https://pith.science/paper/TRWMPMFW

@misc{pith2026260800734,
  author       = {Pith},
  title        = {Pith review of: Conceptual architecture of the detector infrastructure for WST},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/TRWMPMFW}},
  note         = {Machine review of arXiv:2608.00734}
}

read the original abstract

The Wide-field Spectroscopic Telescope (WST) is a proposed 12 m wide-field spectroscopic facility combining several multi-object spectrographs. It requires a yet unprecedented number of detectors. In this paper we present conceptual architecture for the detector controller and infrastructure required to operate a large number of detectors, potentially applicable to WST, focusing on the system-level, power distribution, and the associated data handling. We also consider how these elements may evolve over the expected development timeline of such a facility. Motivated by the scale of the problem, we outline a possible distributed detector-controller architecture, based on modular units placed close to the detectors and networked backend electronics.

Figures

Figures reproduced from arXiv: 2608.00734 by the authors.

**Figure 1.** Minimum number of UTR samples required within a 15 min integration to reach an effective noise of 1e- (blue) and <3e- (orange), as a function of the single-read noise. The horizontal dashed lines give the maximum M supported by the [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗

**Figure 1.** Proposed architecture for the distributed detector readout. Each detector module couples a detector to its local control hardware; groups of detector modules are served by an aggregator / edge-compute node, which performs the first data reduction before forwarding to the compute infrastructure. The edge aggregator is the networked backend unit: it terminates up to 32 links per shelf and executes the in-line UTR proc… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

14 extracted references · 12 canonical work pages

[1]

WST — Widefield Spectroscopic Telescope: motivation, science drivers and top-level requirements for a new dedicated facility,

R. Bacon, V. Mainieri, S. Randich, et al., "WST — Widefield Spectroscopic Telescope: motivation, science drivers and top-level requirements for a new dedicated facility," Proc. SPIE 13094, 130941O (2024)

work page 2024
[2]

D. Lee, J. Vernet, R. Bacon, et al., "WST — Widefield Spectroscopic Telescope: addressing the instrumentation challenges of a new 12 m class telescope dedicated to widefield Multi -object and Integral Field Spectroscopy," Proc. SPIE 13096 (2024); arXiv:2405.19198

work page Pith review arXiv 2024
[3]

An analysis of large astronomical detector controller systems and implications for future ESO detector systems,

M. Richerzhagen, N. Bezawada, S. E. Egner, E. George, A. Meoli, et al., "An analysis of large astronomical detector controller systems and implications for future ESO detector systems," arXiv:2603.17389 (2026)

work page arXiv 2026
[4]

NGC — ESO's New General Detector Controller,

D. Baade, A. Balestra, C. Cumani, et al., "NGC — ESO's New General Detector Controller," The Messenger 136, 20 (2009)

work page 2009
[5]

Multiply sampled read -limited and background -limited noise performance,

J. D. Garnett & W. J. Forrest, "Multiply sampled read -limited and background -limited noise performance," Proc. SPIE 1946, 395 (1993)

work page 1946
[6]

The O2 software framework and GPU usage in ALICE online and offline reconstruction in Run 3

G. Eulisse, D. Rohr, et al. (ALICE Collaboration), "The O2 software framework and GPU usage in ALICE online and offline reconstruction in Run 3," arXiv:2402.01205 (2024)

work page Pith review arXiv 2024
[7]

Allen: a high -level trigger on GPUs for LHCb,

R. Aaij, et al. (LHCb Collaboration), "Allen: a high -level trigger on GPUs for LHCb," Comput. Softw. Big Sci. 4, 7 (2020); doi:10.1007/s41781-020-00039-7

doi:10.1007/s41781-020-00039-7 2020
[8]

Power over Ethernet over 4 pairs (Type 3 and Type 4)

IEEE Std 802.3bt-2018, "Power over Ethernet over 4 pairs (Type 3 and Type 4)."

work page 2018

Show all 14 references

[9]

IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems (PTPv2)

IEEE Std 1588 -2019, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems (PTPv2)."

2019
[10]

MicroTCA.4 — enhancements for rear I/O and precision timing,

PICMG, "MicroTCA.4 — enhancements for rear I/O and precision timing," MTCA.4 R1.0 (2011)

2011
[11]

The White Rabbit project,

J. Serrano, P. Alvarez, M. Cattin, et al., "The White Rabbit project," Proc. ICALEPCS 2009, Kobe, Japan, TUC004

2009
[12]

Sustainability as a design parameter in the early development of the Wide - field Spectroscopic Telescope,

L. Fréour, E. Burtin, R. Bacon, et al., "Sustainability as a design parameter in the early development of the Wide - field Spectroscopic Telescope," Proc. SPIE, this conference (2026)

2026
[13]

Cosmic -ray rejection and readout efficiency for large -area arrays,

D. J. Fixsen, J. D. Offenberg, et al., "Cosmic -ray rejection and readout efficiency for large -area arrays," PASP 112, 1350–1359 (2000)

2000
[14]

Pyxel 1.0: an open source Python framework for detector and end -to- end instrument simulation,

M. Arko, T. Prod'homme, F. Lemmel, et al., "Pyxel 1.0: an open source Python framework for detector and end -to- end instrument simulation," J. Astron. Telesc. Instrum. Syst. 8(4), 048002 (2022); doi:10.1117/1.JATIS.8.4.048002

2022 doi

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.

[1] [1]

WST — Widefield Spectroscopic Telescope: motivation, science drivers and top-level requirements for a new dedicated facility,

R. Bacon, V. Mainieri, S. Randich, et al., "WST — Widefield Spectroscopic Telescope: motivation, science drivers and top-level requirements for a new dedicated facility," Proc. SPIE 13094, 130941O (2024)

work page 2024

[2] [2]

D. Lee, J. Vernet, R. Bacon, et al., "WST — Widefield Spectroscopic Telescope: addressing the instrumentation challenges of a new 12 m class telescope dedicated to widefield Multi -object and Integral Field Spectroscopy," Proc. SPIE 13096 (2024); arXiv:2405.19198

work page Pith review arXiv 2024

[3] [3]

An analysis of large astronomical detector controller systems and implications for future ESO detector systems,

M. Richerzhagen, N. Bezawada, S. E. Egner, E. George, A. Meoli, et al., "An analysis of large astronomical detector controller systems and implications for future ESO detector systems," arXiv:2603.17389 (2026)

work page arXiv 2026

[4] [4]

NGC — ESO's New General Detector Controller,

D. Baade, A. Balestra, C. Cumani, et al., "NGC — ESO's New General Detector Controller," The Messenger 136, 20 (2009)

work page 2009

[5] [5]

Multiply sampled read -limited and background -limited noise performance,

J. D. Garnett & W. J. Forrest, "Multiply sampled read -limited and background -limited noise performance," Proc. SPIE 1946, 395 (1993)

work page 1946

[6] [6]

The O2 software framework and GPU usage in ALICE online and offline reconstruction in Run 3

G. Eulisse, D. Rohr, et al. (ALICE Collaboration), "The O2 software framework and GPU usage in ALICE online and offline reconstruction in Run 3," arXiv:2402.01205 (2024)

work page Pith review arXiv 2024

[7] [7]

Allen: a high -level trigger on GPUs for LHCb,

R. Aaij, et al. (LHCb Collaboration), "Allen: a high -level trigger on GPUs for LHCb," Comput. Softw. Big Sci. 4, 7 (2020); doi:10.1007/s41781-020-00039-7

doi:10.1007/s41781-020-00039-7 2020

[8] [8]

Power over Ethernet over 4 pairs (Type 3 and Type 4)

IEEE Std 802.3bt-2018, "Power over Ethernet over 4 pairs (Type 3 and Type 4)."

work page 2018