CubeSat Gamma-Ray Burst Timing Payload — Rev A

Detect gamma-ray bursts, measure the arrival time and approximate energy of their gamma-ray photons, and provide accurately synchronised burst data for comparison with other satellites and observatories.

The intended satellite would detect short and long gamma-ray bursts, measure individual gamma-ray pulse arrival times, estimate the energy of each detected photon, produce a time-dependent gamma-ray light curve, identify sudden increases above the normal background count rate, send rapid burst alerts to the spacecraft and ground station, compare events with Fermi, Swift, GECAM, gravitational-wave observatories and other CubeSats, and support timing-based GRB localisation when used as part of a satellite network.

The last of those is the one most easily overstated, and the source states it carefully. Localisation is something the payload supports as part of a network. It is not something a single spacecraft does.

A gamma-ray burst lasts from a fraction of a second to a few minutes, and the information in it is carried by how its brightness changes over that interval and how energetic its photons are. An instrument that records arrival time and approximate energy for individual photons has recorded the burst.

Direction is a separate problem with a separate solution. A single satellite can detect and time a burst, but it cannot determine a precise direction by arrival-time triangulation on its own. At least two separated satellites can generate a possible sky annulus from the difference in arrival time. Three or more properly separated detectors can produce a better location estimate. NASA's Interplanetary Network uses exactly this: differences in GRB arrival time between spacecraft, converted into a position on the sky.

That is why the clock requirement on this payload is what it is. A timestamp accurate to 10 microseconds is not housekeeping precision; it is the quantity a network would use. A detection with an untrustworthy time contributes nothing to a network, however good the detector behind it.

A gamma ray is detected indirectly. It deposits energy in a scintillator crystal, the crystal emits a brief flash of visible light, a silicon photomultiplier converts that flash into a short electrical pulse, and the electronics measure the pulse.

Two quantities come out of one pulse, and they answer different questions.

The timing path asks when. The detector pulse goes to a comparator, the comparator produces a digital edge when the pulse crosses a threshold, the edge is captured by an STM32 hardware timer, and firmware converts the capture into a calibrated event timestamp. What matters along this path is latency and its stability: every fixed delay has to be measured so it can be subtracted, and variation in that delay is the error that cannot be subtracted.

The energy path asks how big. The same detector pulse goes to a low-noise amplifier, then to a shaping or peak-hold stage that stretches it, then to a pulse-height ADC, which produces a digital amplitude that ground software converts into an estimated photon energy. What matters along this path is amplitude fidelity: gain, linearity, and whether the converter is actually measuring the peak of the pulse rather than some point on its way up or down.

The calibration requirements differ accordingly. The timing path is calibrated against a reference clock and a reference pulse. The energy path is calibrated against known gamma-ray energies at a licensed radiation facility. Neither calibrates the other.

Rev A contains a comparator, an amplifier and an ADC. It does not contain the shaping or peak-hold stage, and it does not show the comparator connected to a hardware timer-capture input. Both paths are incomplete.

The detector head is the primary science payload, and the current schematic does not show this assembly at all.

What it is intended to include: a gamma-sensitive scintillator crystal, a silicon photomultiplier or SiPM array, optical coupling material between them, reflective wrapping around the crystal, a light-tight external enclosure, a temperature sensor, and shielding and mechanical support.

Each of those has a job. The crystal converts gamma-ray energy into visible photons, and its choice sets the energy range and the achievable resolution. The optical coupling carries that light into the SiPM without losing it, and it has to keep doing so after launch vibration, because a coupling that shifts changes the amplitude delivered for the same deposited energy — which is a change in the energy scale. The reflective wrapping returns light that would otherwise leave the crystal in the wrong direction. The enclosure keeps external light out, because a SiPM cannot distinguish a stray photon from a scintillation flash. The temperature sensor exists because SiPM gain moves with temperature.

The source lists CsI(Tl), CeBr3 and other gamma-sensitive crystals as candidates. It does not select one, and neither do these notes. Detector selection is future design work, and it is the first item on the Rev B list.

Also absent is the connector the detector head would attach through: the SiPM signal, its bias, its temperature reading and its ground all have to cross from the detector assembly to the board, and Rev A provides nothing for them.

The silicon photomultiplier converts the scintillation flash into an electrical pulse, and it is the device the whole analog chain is sized around.

The requirement is that it converts scintillation light into electrical pulses with sufficient gain, with the acceptance criterion that a controlled optical pulse creates a repeatable output pulse. The planned test is deliberately independent of gamma rays: a pulsed LED illuminating the SiPM inside a light-tight enclosure. That test can be run long before any radiation facility is involved, and it separates a detector problem from an electronics problem.

Two properties of a SiPM shape everything downstream. Its pulses are short, which is why a shaping or peak-hold stage is needed before amplitude can be measured. And it produces dark counts — thermally generated pulses indistinguishable from small real ones — which is why the trigger has to reject low-level pulses rather than accept everything above the noise floor.

No SiPM has been selected. The device is part of the detector head that Rev A does not contain.

U10, a boost converter, is intended to produce the SiPM operating voltage — approximately 25 to 30 V, stepped up from the payload's 3.3 V rail.

The bias requirement is tighter than a power-supply requirement normally is, because SiPM gain follows bias closely. The acceptance criterion is that bias remains within 0.1 V of its command value, verified across input voltage, load and temperature. A bias that wanders is an energy scale that wanders, and an energy scale that wanders invalidates the spectrum.

The supply also has to fail safely. The requirement is that it limits current during a SiPM or cable fault, with the acceptance criterion that a simulated short does not damage the payload or the spacecraft power bus. The planned test uses a current-limited dummy load to simulate that fault.

The review adds three things Rev A does not have: closed-loop bias feedback, measurement of the actual bias voltage, and controlled discharge. Feedback is what turns a commanded voltage into a delivered one. Measurement is what lets telemetry confirm it. Controlled discharge matters because a high-voltage node left charged is a hazard to the detector and to anyone handling the hardware.

SiPM gain changes with temperature. That is a physical property of the device, not a defect, and an instrument that ignores it reports a drifting energy scale as if it were science.

TR-11 requires that SiPM gain changes caused by temperature are measured or compensated. The compensation requirement is that bias or software calibration corrects for SiPM temperature changes, with the acceptance criterion that a reference pulse peak remains within 5 per cent over the operating range. The planned test repeats optical-pulser measurements inside a thermal chamber.

U6 measures SiPM and board temperature, with its own requirement of 2 degrees Celsius accuracy, verified against calibrated chamber probes during thermal cycling. The review's point is that U6's readings have to feed compensation, not only telemetry. A temperature that is recorded but not acted on documents the drift instead of removing it.

Two mechanisms are available and the source does not choose between them: adjust the bias to hold gain constant, or record the temperature and correct the energy scale on the ground. Selecting one is Rev B work.

U2 is the low-noise pulse amplifier that lifts the small SiPM pulse to a level the rest of the chain can work with.

The requirement is that it amplifies minimum detector pulses without excessive distortion, with the acceptance criterion that minimum valid pulses have at least 6 dB signal-to-noise ratio. Verification injects calibrated electrical and optical pulses at several amplitudes.

Its exact part number is not specified in Rev A, which means the noise figure and bandwidth the requirement depends on are not yet established. An amplifier's noise sets the smallest pulse that can be distinguished from nothing, and its bandwidth decides whether a short SiPM pulse arrives at the comparator with its shape intact or already smeared. Both are consequences of a part that has not been chosen.

The amplifier is also the first element in the timing chain, so its latency is one of the delays that has to be measured and corrected. That is covered under timing-latency calibration below.

This stage is required and it is not in Rev A.

The problem it solves: a SiPM pulse is far too brief for a pulse-height converter to catch at its peak. A converter samples at a moment; if the pulse has already passed its maximum by then, the digitised number is not the amplitude of the pulse but an arbitrary point on its decay. The measurement would still produce numbers. They would not mean energy.

The source states the requirement as a shaping or peak-hold circuit that stretches the pulse for ADC measurement, with the acceptance criterion that pulse-height error remains below 5 per cent, verified by comparing ADC measurements against an oscilloscope and a precision pulser.

No topology is proposed here. The source does not specify one, and the choice interacts with the SiPM and the amplifier that have also not been selected. What can be said is what the absence means: every requirement downstream that depends on amplitude — 12-bit digitisation, 2 ADC counts of measurement error, 10 per cent initial energy accuracy — currently rests on a stage that does not exist. It is item 3 on the Rev B list.

P1 is the fast event comparator. It produces a digital edge when a detector pulse crosses a selected threshold, and that edge is what the instrument treats as the arrival of a photon.

The requirement is that P1 generates a trigger when a pulse crosses the selected threshold, with the acceptance criterion that at least 95 per cent of valid pulses above threshold trigger. Verification sweeps pulse amplitude through the comparator threshold and counts what gets through.

The threshold is a compromise that has to be made deliberately. Set it low and SiPM dark counts and baseline noise become events, filling storage with nothing and raising the false-trigger rate. Set it high and real low-energy photons at the bottom of the 50 keV target range are discarded. The separate noise-rejection requirement states the other half: the trigger system rejects baseline noise and low-level SiPM dark pulses, with a false-event rate below a mission limit that has still to be selected, tested in a dark, radiation-controlled enclosure.

P1's part number is unspecified. Its propagation delay and its variation with input amplitude are timing-chain terms, so the part choice has consequences for the 1 microsecond electronic-timing target.

U3 digitises the shaped pulse amplitude, which is the estimate of photon energy.

TR-04 requires at least 12-bit digitisation. The function-level requirement adds the accuracy: measurement error within 2 ADC counts after calibration, verified by applying precision voltages and shaped pulses across the ADC range.

Converting that number into an energy is a separate step performed in software, with its own requirement: known calibration peaks initially appear within 10 per cent of their accepted energies, established by energy calibration at a licensed radiation facility. "Initially" is doing real work in that sentence — it is a first-light acceptance figure, not a final resolution claim.

The chain of dependencies is worth stating plainly. The energy estimate depends on the ADC, which depends on the shaping stage that does not exist, which depends on an amplifier whose part is unchosen, which depends on a SiPM and scintillator that are not on the schematic. Rev A settles the last link and none of the earlier ones.

The comparator output has to reach an STM32 hardware timer-capture input. Rev A does not show that connection, and it is item 4 on the Rev B list.

The reason it must be hardware rather than software is the acceptance criterion attached to it: electronic timing variation below 1 microsecond. A software interrupt responds after a delay that depends on what the processor was doing — whether it was mid-instruction, whether a higher-priority interrupt was pending, whether it was writing to flash. That variation is not fixed, so it cannot be calibrated out. A hardware capture unit latches the timer value at the moment the edge arrives, independently of what the processor is doing, and the processor reads the latched value whenever it gets round to it.

The planned verification sends simultaneous pulses to the payload and to reference timing equipment and compares what each recorded.

X1 at 12 MHz and X2 at 8 MHz are the clock sources on the sheet. The review requires the STM32 clock circuit to be verified with correct load capacitors, which is ordinary crystal-circuit diligence made less ordinary by the fact that this clock is the measurement reference between GNSS updates.

GNSS provides the absolute reference the event timer is disciplined against. The requirement is that GNSS 1-PPS synchronises the event timer, with the acceptance criterion that absolute timing error remains below 10 microseconds, verified against a GNSS-disciplined reference system.

What GNSS does not do is worth stating explicitly, because it is easy to assume otherwise. A 1-PPS edge tells the payload when a second begins. It says nothing about how long the photon took to travel from the crystal through the SiPM, the amplifier and the comparator before the edge that was timestamped appeared. That delay is real, it is part of every event time, and removing it is a separate calibration exercise described in the next section. GNSS fixes the origin of the time axis; it does not fix the offset between the event and the record of it.

Rev A contains two GNSS modules, U5 and U11, each with 1-PPS outputs and antenna connections. The source says the two modules may provide timing redundancy, but their roles need to be clearly defined. That is where it stands: a possibility recorded in the review, not an implemented scheme. Which module disciplines the timer, whether the second is a hot spare, a cross-check or something else, and what happens when they disagree, are all undefined in Rev A, and defining them is item 9 on the Rev B list.

There is also a labelling problem with real consequences. Both antenna symbols on the sheet are labelled 6 GHz, which does not match a normal GNSS antenna band. The review requires the label to be corrected and the antenna verified. It is left as drawn here, and reported, rather than silently fixed: the finding is that the timing subsystem's antenna specification has not been settled, and correcting the label on a page would hide that.

The intended event-time chain has more links than the timestamp suggests: detector response, amplifier latency, comparator latency, cable delay, hardware timer capture, GNSS 1-PPS synchronisation, local clock behaviour between edges, and firmware correction.

Every one of those contributes delay between the photon interacting in the crystal and the timer value being latched. The source requires that amplifier, comparator, cable and firmware latency be measured, with the acceptance criterion that corrected timestamps meet the timing requirement. The planned method is a split pulse: one pulse sent to both the payload and reference equipment, so the difference between what each recorded is the payload's delay.

The distinction that matters is between fixed delay and variation. A fixed delay can be measured once and subtracted in firmware or on the ground, and it stops being an error. Variation in that delay cannot be subtracted, because there is no single number to subtract — it is what the 1 microsecond electronic-timing-variation requirement is about, and it is the reason the capture has to be in hardware.

A delay that has not been measured is an error that cannot be removed. Rev A calibrates none of them, because there is nothing to calibrate yet.

GNSS 1-PPS arrives once per second. Every event between two edges is timed by the local clock, so the local clock's stability over that interval is part of the timing budget.

The requirement is that a stable local clock maintains time between 1-PPS updates, with the acceptance criterion that drift remains inside the timing allocation during the required holdover period. Verification removes 1-PPS for controlled intervals and measures the drift that accumulates.

Holdover is not only about GNSS hardware failure. A CubeSat can lose lock passing through the shadow of its own structure, during attitude manoeuvres, or when the antenna is pointed away from the constellation, and the payload keeps detecting photons throughout. What it must not do is keep producing timestamps that claim an accuracy it no longer has.

Hence the separate detection requirement: firmware detects missing or invalid GNSS synchronisation, and unsynchronised records receive a timing-quality warning. Verification disconnects the GNSS antenna and the 1-PPS signal during operation to confirm the flag appears. A record that is honest about being degraded is still useful. A record that is silently wrong is worse than no record.

U1, an STM32F103C8T6, controls the payload and processes events. X1 at 12 MHz and X2 at 8 MHz provide the processor and timing clocks.

Its responsibilities span nearly everything in these notes: reading captured timestamps and digitised pulse heights, counting accepted events in programmable time bins, maintaining the running background estimate, running the burst-detection logic across several integration windows, managing the circular pre-trigger buffer, writing records to flash, generating the alert packet, servicing the spacecraft interface, reading temperature and power housekeeping, and entering safe mode when something is wrong.

Two of those interact awkwardly and the interaction is a design constraint rather than an implementation detail. Flash writes take time during which the processor may not be able to accept another event, which is part of the dead-time budget. And the same processor is expected to recover from its own failures: TR-14 requires automatic recovery from processor, timing and storage faults, with a watchdog restarting the processor after a software failure and the payload returning to safe mode within 60 seconds. Verification forces a lockup deliberately.

The hardware watchdog and safe-mode circuit are item 17 on the Rev B list. Rev A does not show them.

Counting events and knowing when the detector cannot accept another event are two different measurements, and the source treats them separately.

Counting is the straightforward one: the processor counts accepted pulses in programmable time bins, with the acceptance criterion that recorded counts match injected counts after dead-time correction. Verification injects a known number of pulses at several rates.

Dead time is the correction in that sentence. After a pulse is accepted, there is an interval during which the instrument is busy — shaping still settling, the converter still converting, the processor still recording — and any photon arriving in that interval is not counted. The instrument does not know it missed them. Left uncorrected, a bright burst appears to be dimmer than it was, precisely when the light curve matters most, because a high count rate produces more dead time than a low one.

So the payload is required to measure or calculate when it cannot accept another event, with live time remaining at or above 90 per cent under nominal conditions. Verification increases the injected pulse rate until events are lost, which is how the relationship between rate and live time is established rather than assumed.

The 90 per cent figure is a nominal-background requirement. It is not a measured live time, and it is not a claim about behaviour during a bright burst.

A gamma-ray burst is recognised as an increase above background, which means the instrument has to know what its background currently is.

The requirement is that the processor maintains a running background count-rate estimate, with the acceptance criterion that slow background changes do not create repeated false triggers. Verification replays simulated orbital-background profiles.

The orbital background is not constant. It varies with position along the orbit, with geomagnetic latitude, and sharply through regions of trapped radiation. A fixed threshold set for a quiet part of the orbit would trigger continuously in a noisy one; a threshold set for the noisy part would be deaf in the quiet one. The estimate therefore tracks slowly, so that genuine slow variation is absorbed into the background rather than reported as a series of bursts.

The consequence is a time-constant trade-off the source does not fix numerically: track too fast and a real burst is partly absorbed into the background it should be standing out from; track too slowly and an orbital transition is reported as an event.

The detection sequence the payload is required to perform, in order: maintain a running background estimate, evaluate count rates across multiple time windows, identify a statistically significant increase above that background, declare a candidate burst, preserve the data from before and after the trigger, and generate a rapid alert.

TR-06 states the requirement: the payload autonomously identifies statistically significant increases above background. The acceptance criterion is that at least 90 per cent of simulated bursts above the sensitivity threshold trigger, verified by mixing simulated GRBs into measured background data.

"Statistically significant" is the operative phrase and it is doing necessary work. Photon arrivals fluctuate; a count rate a little above average is expected and means nothing. The significance test is what separates an ordinary fluctuation from an event, and it is what keeps the false-trigger rate low enough that the alert path stays meaningful.

Nothing here has been implemented or tuned. These are requirements on firmware that does not exist yet, to be tested against simulated bursts rather than real ones.

A single integration window cannot detect both classes of burst.

Short gamma-ray bursts last well under a second; long ones last tens of seconds. A window long enough to accumulate significance on a long, faint burst averages a short one away into the background. A window short enough for a short burst collects too few counts to establish significance on a long faint one.

The requirement is therefore that triggering evaluates short and long integration windows, with the acceptance criterion that short and long simulated bursts both trigger. The source proposes windows such as 16 ms, 64 ms, 256 ms and 1.024 s for that testing.

Those four values are proposed test and trigger windows from the design review. They are not validated settings, and nothing has been run through them. Which windows a flight version would use, and how significance is combined across them, is future work.

Two different things can masquerade as photons, and they are rejected in two different places.

At the bottom of the amplitude range, baseline noise and low-level SiPM dark pulses can cross a threshold set too low. That is the comparator's problem, handled by threshold selection, with the requirement that the false-event rate remains below a mission limit still to be selected, tested in a dark, radiation-controlled enclosure.

At the top, charged particles passing through the detector deposit energy directly and produce large pulses that are perfectly real signals from perfectly uninteresting events. The requirement is that software identifies isolated high-energy particle interactions, with the acceptance criterion that particle-like pulses do not create excessive GRB alerts. Verification replays simulated particle pulses through the trigger algorithm.

The word "isolated" is the discriminator the source offers: a burst is a sustained rise in rate across many photons, while a particle interaction is a single large deposit. Rejecting them is a firmware requirement, not a circuit one, and nothing has been written or tested.

By the time a count-rate increase has been recognised as statistically significant, the beginning of the burst has already happened. No threshold setting recovers data that was never kept.

A circular buffer solves it the same way it does in any triggered instrument: the payload records continuously into memory that overwrites itself, so when a trigger fires the preceding interval is still in hand. The requirement is at least 30 seconds of pre-trigger data retained, with the saved record inspected after injecting a test burst to confirm it.

Recording continues after the trigger, with at least 120 seconds preserved and the record duration verified the same way. Two minutes is not arbitrary: long bursts run for tens of seconds and the decay afterwards is part of the light curve.

A related requirement protects what has been captured. Confirmed burst data is protected from automatic overwriting, with the acceptance criterion that priority files remain after storage reaches capacity, verified by filling flash while monitoring the protected files. Without it, the most valuable record in the instrument is the one a long quiet period would eventually erase.

The schematic contains flash memory U4 and SPI flash memory U14.

The source does not define their final separate roles, and neither do these notes. What is defined is what has to be stored: photon event lists, gamma-ray light curves, burst-trigger data, background measurements, timing information, temperature and power data, and fault and reset logs.

The storage requirement is about survival rather than capacity. Flash memory stores time, pulse height, flags, temperature and detector state, with the acceptance criterion that at least 99 per cent of records pass checksum verification. Verification is deliberately hostile: repeated writes, power interruptions during writes, filling the memory, and readback tests.

Power interruption is the interesting case. A write interrupted halfway can leave a partial record, and a partial record that is not detectable as partial is worse than a missing one, because it will be analysed. Checksums are what make the difference between a record that is known to be bad and a record that is quietly wrong.

Defining the roles of the two devices is item 10 on the Rev B list.

TR-09 requires a rapid alert packet within 10 seconds of a confirmed trigger. Firmware creates a compact alert after confirming a burst, with the acceptance criterion that the spacecraft computer receives it within 10 seconds, verified by measuring the time from an injected burst to the output packet.

Ten seconds is short for a satellite and long for a burst, which is the point. The alert is not the science data; it is a notification that lets other instruments and observatories know something happened and roughly when. The full event record follows later through the normal downlink.

The word "confirmed" is what separates this from the trigger itself. An alert is an outward-facing claim, and a payload that alerts on every fluctuation is a payload other observatories stop listening to.

The alert travels over the spacecraft interface, which is the subject of the next section, and which Rev A has not defined.

U12 and U13 are the connectors between the payload and the spacecraft, carrying power and data. Their pin functions are not labelled on the sheet, and labelling them is item 13 on the Rev B list.

The requirement is that U12 or U13 provides a defined flight data interface, with the acceptance criterion that a 24-hour test produces no uncorrected communication errors. Verification runs the payload continuously against a spacecraft-computer emulator.

Two things cross this interface and they have different urgency. The alert packet has ten seconds to arrive. The science records — event lists, light curves, background, housekeeping — go whenever the spacecraft can take them, and downlink is the spacecraft's job rather than the payload's.

An undefined interface is not a small gap. Every number in these notes that describes what reaches the ground assumes a working path from U1 to the spacecraft computer, and that path is currently two unlabelled headers.

The review requires separate analog and digital grounding with power filtering, and it is item 14 on the Rev B list.

The reason is the same one that governs the rest of the analog chain: the instrument is trying to measure pulses close to its own noise floor, on a board that also contains a microcontroller running at 12 MHz, a boost converter switching to nearly 30 V, an SPI bus writing to flash, and status LEDs. Current from any of those returning through a shared ground path develops a voltage across that path, and that voltage adds directly to the small signal the amplifier is trying to resolve.

The separate analog 3.3 V regulator U9 is half of the answer. Separated ground return paths and supply filtering are the other half, and Rev A does not establish them.

The corresponding requirement is stated in terms of what must not happen: digital clocks and switching converters do not prevent valid pulse detection, with analog noise remaining within the sensitivity requirement. Verification compares baseline noise with individual subsystems turned on and off — the only method that attributes a noise contribution to the thing producing it.

The review also asks for test points at bias, amplifier output, comparator output, ADC input, 1-PPS and the supply rails. Without them, none of the measurements in the verification matrix can actually be taken on hardware.

TR-16 requires ground software to compare detected events with observations from other gamma-ray and gravitational-wave instruments. The named comparisons are Fermi, Swift, GECAM, gravitational-wave observatories and other CubeSats.

The requirement is that ground software compares timestamps and light curves with external observations, with the acceptance criterion that confirmed events match independent detections within combined timing uncertainty. Verification uses historical GRB observations to test the analysis system before any of the payload's own data exists.

Two details in that acceptance criterion carry the weight. "Combined" timing uncertainty means the comparison is only as good as the less certain of the two clocks, which is why a 10 microsecond requirement on this payload is worth having rather than excessive. And matching against historical observations is how the analysis software can be built and tested before launch, independently of whether the hardware is ready.

This is also where a detection stops being a local measurement. An unconfirmed transient seen by one CubeSat is a candidate; the same transient agreeing in time with an established observatory is an observation.

The hierarchy in the source is precise and worth keeping precise.

One satellite detects a burst and timestamps it. It cannot determine a direction by arrival-time triangulation on its own — there is no baseline to measure a difference against.

Two separated satellites can compare the arrival time of the same burst. The difference constrains the source to a possible annulus on the sky: a ring of directions consistent with that time difference, not a point.

Three or more properly separated detectors add further baselines, and the intersection of the constraints produces a better location estimate. NASA's Interplanetary Network works this way, using arrival-time differences between widely separated spacecraft.

The corresponding verification requirement is that multiple satellites provide synchronised light curves for the same event, with the acceptance criterion that analysis recovers known simulated arrival-time differences. The test method is entirely synthetic: time-shifted copies of a GRB light curve sent through multiple payload emulators, which is how the analysis can be exercised without a constellation.

What this project does not have: a second spacecraft, a network, a deployed anything, or any angular accuracy figure. This section describes mission architecture and future science use. A single Rev A schematic contributes one potential node, and only if its clock can be trusted.

TR-15 requires the payload to survive launch vibration and its expected orbital temperature range. The function-level requirement is broader: the payload tolerates vibration, vacuum, temperature cycling and expected radiation effects, with the acceptance criterion that calibration and functional tests pass after environmental testing.

The planned campaign is vibration testing, thermal-vacuum cycling, radiation analysis, and post-test calibration. The last is the one that matters most for this instrument. A detector that survives vibration mechanically but whose optical coupling has shifted will still produce pulses; they will simply mean something different than they did before. That is why the coupling requirement is stated as amplitude changing by less than 5 per cent after vibration, with reference optical measurements taken before and after.

Radiation gets a second entry on the Rev B list as latch-up and radiation-effects analysis. An instrument designed to detect ionising radiation sits in an environment full of it, and the same particles that produce the background it has to estimate can also upset the processor and memory that record it. TR-14's automatic recovery requirement is the operational half of that answer; the analysis is the design half, and it has not been done.

What the drawing settles, and what it does not.

It settles the support electronics. A payload computer with its clocks, an amplifier, a comparator, a pulse-height converter, two GNSS modules with 1-PPS outputs, two flash devices, a boost converter for SiPM bias, separate digital and analog regulators, temperature and power monitoring, input protection, spacecraft headers and status LEDs. That is a coherent set of parts for a pulse-processing payload.

What it does not settle starts with the instrument. There is no scintillator, no SiPM, no optical coupling, no light-tight enclosure, and no connector for any of them. Everything on the sheet processes a pulse; nothing on it produces one.

Inside the analog chain, the shaping or peak-hold stage is missing, so amplitude measurement has no stage that makes it reliable. The comparator is not shown reaching a hardware timer-capture input, so the timing path has no stage that makes it precise. And U2, P1 and U3 have no exact part numbers, so the amplifier noise, comparator speed and converter accuracy that the requirements depend on are not yet established quantities.

The bias supply needs closed-loop feedback, current limiting, voltage measurement and controlled discharge. Gain compensation from the temperature sensor needs to exist as a mechanism rather than a reading.

Then the ambiguities. Two GNSS modules whose individual roles are undefined — the source says they may provide timing redundancy, and that is as far as it goes. Two flash devices whose separate roles are likewise undefined. And both antenna symbols labelled 6 GHz, which does not match a normal GNSS antenna band and has to be corrected and verified rather than assumed to be a typo.

Finally the items a schematic makes easy to postpone: separate analog and digital grounding with filtering, test points at every node the verification plan needs to probe, labelled spacecraft-interface pins, a hardware watchdog and safe-mode circuit, a latch-up and radiation analysis, a light-tight enclosure, a detector calibration plan, and a ground-processing and cross-satellite timing pipeline.

Nothing in this review has been resolved by testing. There is no board.