Answers and comments on What is the data storage capabilities onboard the James Webb Telescope? which reference the James Webb Space Telescope User Documentation item JWST Solid State Recorder mention that JWST's total onboard storage capability is almost 59 GB, and that

The rate at which science data can be written to the SSR is regulated by the ISIM Command and Data Handling subsystem (ICDH). The maximum ICDH sustained data rate is about 48 Mbits per second, including data packetization overheads. This corresponds to about six 2048 × 2048 full frame image files every 10.7 s...

48 Mbits/sec is 6 MB/sec and that would fill 59 GB in about 160 minutes if it ran flat out which it wouldn't always do.

Question: Some deep space telescopes have onboard data processing capabilities to reduce the burden on the downlink, for example GAIA has a SCS750 PowerPC Board with triple redundancy and TESS has an Athena-3 Single Board Computer (SBC) (and) a Re-Configurable Computer (RCC) with three Virtex-5 FPGAs. What are the general properties and specs for JWST's onboard data and image processing capabilities? Is there a rack full of processors or GPUs? A total gigaflop specification?

As an aside, TESS has 192 GB of mass data storage or three times what JWST will have!

  • 1
    $\begingroup$ The JWST source I used to answer the linked question only said that the storage was "at least 59GB" and since that was a 2017 document, they may have upgraded. On the other hand the download bandwidth limit is likely to be much more rigid, so either avoiding taking images at maximum speed, or doing some on board data compression or cropping or whatever will clearly still be essential. $\endgroup$ Apr 29, 2020 at 7:57
  • 4
    $\begingroup$ TESS is a survey instrument with lots of CCDs designed for a wide field view and short exposures for time series and exoplanet detection. JWST has a tiny field of view and is designed for deep stares and long spectroscopic exposures so it's data storage needs are totally different. $\endgroup$ Apr 29, 2020 at 14:43
  • 1
    $\begingroup$ Just conjecturing here, but one of the biggest design goals of the JWST seems to be keeping the instruments cool. So a big, hot processing array might be a bit counterproductive. Also keep in mind that much of astronomy is long term exposure, on the scale of minutes, if not hours per image. If your observation produces its image after a few seconds, then what you are looking at will likely be so bright that it can be seen from earth anyway. $\endgroup$
    – mlk
    Apr 29, 2020 at 14:43
  • 3
    $\begingroup$ Normally onboard processing is avoided unless you are forced into it by data rate downlink considerations (bandwidth to ground station). It also much easier to do for single purpose observing as TESS and Gaia do than for general science observatories like JWST - how do guarantee you won't destroy or prevent someone's science with the processing if they do something it doesn't expect ? More info on the processing and data/rate limits in the JWST proposal preparation docs, $\endgroup$ Apr 29, 2020 at 16:25
  • 2
    $\begingroup$ The ICDH system contains three FPAP cards where the extracted raw data is averaged (to conserve bandwidth) before being saved to the SSR, and subsequently downlinked to ground stations. Actual spec data for the FPAP cards is hard to find. $\endgroup$ May 5 at 10:49

2 Answers 2


The JWST uses one RAD750 clocked at 118 MHz which is based on the PowerPC 750.

enter image description here

Not sure if JWST uses the 3U or 6U version. Below is the CPU architecture for the 6U from this thesis.

enter image description here

This report contains a table of processors.

enter image description here

Slides 59 and 60 might be of interest to you too. They discuss the SW layers, components, and flight software "app store".

Having spent a fair amount of my career working on image processing (GPUs and full custom cores mainly), I can share with you that it doesn't take much processing power to compress images that are mostly black, when your goal is near-lossless compression, your frame rate is very low, and you don't really care about latency. It seems like the processor's real duties involve running "Software resident on the ICDH [that] analyzes portions of the data for target acquisition purposes." (ref)

There is also a paper entitled "The James Webb Space Telescope Integrated Science Instrument Module" that discusses the Focal Plane Array Processor (PFAP). You can find it here. The name suggests that they are used for running algorithms that focus the adaptive optics, which may be a relatively compute intensive task.

enter image description here

  • $\begingroup$ I saw the same sources and diagrams but for me they didnt have the details / specs of the FPAP boards themselves, which are the boards the image data gets shifted to for processing, even if it is just averaging down for bandwidth. Difficult to answer "general properties and specs for JWST's onboard data and image processing capabilities" with the material i've seen. (IIRC the 750 is used for the flight sw rather than image processing) $\endgroup$ May 11 at 13:21
  • $\begingroup$ Thanks for your anwer! 1) "The JWST uses one RAD750 clocked at 118 MHz which is based on the PowerPC 750." Do you mean one processor just "for onboard data and image processing capabilities", or one processor for the entire observatory? 2) There's no redundancy? Just exactly one? $\endgroup$
    – uhoh
    May 11 at 13:31
  • $\begingroup$ Yes, that's the impression that I got. There's some redundancy built into it (e.g. triple flash) but I did find anything that suggested to me that there were multiple RAD750 units onboard for redundancy. $\endgroup$
    – phil1008
    May 11 at 17:25
  • $\begingroup$ @blobbymcblobby Yes, there's not a lot of great info on the image processing but I suspect that this is because it's just not a highlight of the telescope, and it's not really a limitation either. Writing reports about it would be like touting the merits of the Bugatti Veyron's USB port. If I receive the bounty, I'll post it back onto another unanswered question. I just don't want it to go to waste. Let me know if you have any suggestions. $\endgroup$
    – phil1008
    May 11 at 20:07
  • 1
    $\begingroup$ I just replied to a comment but I don't think the commenter's questions revealed a deficiency in the question. But I'll tweak it anyway. $\endgroup$
    – phil1008
    May 12 at 7:27

Not really an answer as I cannot find anything ..solid on specs and hardware

TL;DR - the other answer instead provides hardware specifications.

So instead:

What follows is a bunch of notes that I kept when searching for references to what I perceived as the image processing side of the ISIM system.

enter image description here

The IC&DH provides the centralized ISIM Command and Data Handling functions for the NIRCam, NIRSpec, MIRI, and FGS instruments and unifies the Image collection with a common Spacewire point to point topology.
The JWST IC&DH is unique in that it centralizes the C&DH functions for NIRCam, NIRSpec, MIRI, and FGS away from the detector electronics region in order to manage stringent thermal requirements while maintaining the ability to receive image data at peak detector readout rates. Multiple SpaceWire 4-port Routers within the IC&DH and IRSU provide high speed extraction of image data from each of the instruments and data routing to each of the Focal Plane Array Processors (FPAP). The FPAPs are unique in that they are dynamically configurable and assignable to any one of the 18 total NIRCam, NIRSpec, MIRI, and FGS instrument Sensor Chip Assemblies.

Data Acquisition Function is implemented as several tasks that collaborate to marshal science image data through the system to the SSR, and for providing selected image data to other tasks to support boresight guiding and target acquisition. Image data from science observations is never processed by the ISIM Processor. To perform a science data exposure, the user first configures the Data Acquisition Task specifying the entire sequence of images that the exposure is expected to generate. Data Acquisition uses this information to generate a set of frame processing instructions, which it loads into one of the 18 channels provided by the three Focal Plane Array Processor (FPAP) cards. If multiple detectors will be exposed simultaneously, a separated channel is configured for each detector. Once configured, the Data Acquisition Task and the FPAP channels wait for the arrival of science data.

When the exposure is commanded to start, data flows into the designated FPAP channel and each frame is processed in accordance with the associated frame processing instruction, which includes information about when to output an image to the SSR.

All the image processing is done by the hardware channel so very little CPU time is consumed to capture and record science data.

The Data Acquisition Task responds to interrupts and creates header and trailer records for the file sent to the SSR and then triggers the various elements in the science data path to orchestrate the movement of data from the FPAP channels to the SSR.

Data Acquisition can also be commanded to retrieve image data subwindows and either write them to files or send them in packets so that the locations of stars can be determined. The FGS System uses this data to send guidance information to the spacecraft CTP to stabilize the telescope by fixing on a guide start.





Process: Data acquision from SI (telescope side) - data dumped to FPAP boards (ICDH sub system of ISIM, spacecraft side) - Task processes assigned and carried within this board and assigned between 3 dedicated processors - possibly vision chips - > development of CMOS chips for dedicated digital data processing - data prepared for download (lossless compression (using at least a 2:1 lossless data compression averaged over one day.) and formatting) -> sent to SSR to be stored - > downloaded to Grand stations on schedule.

FPAPs appear to be dedicated towards image processing since they also process star images used for guidance information by the spacecraft command and telemetry processor .

A generic sequence of events in a typical science observation with a JWST instrument would be:

  1. The spacecraft slews to a new target field.
  2. The FGS performs a guide star acquisition and the spacecraft fine points the Observatory.
  3. Configure the appropriate science instrument as necessary.
  4. If necessary, take target acquisition images with the visit’s prime SI. The IC&DH autonomously processes these data to determine and request the corrective small angle offset to place the science target(s) at the required location in the SI FOV.
  5. Configure the instrument for the science observation.
  6. Obtain contemporaneous calibration data (e.g., wavelength calibration exposures).
  7. Take an exposure and read out the detectors.
  8. During and following the exposure, the IC&DH performs any necessary processing of the data and transfers it to the SSR. (This is when data is sent to the FPAP boards for processing and compressing, before saving to SSR)
  9. Perform a small angle offset (dither) as part of the spatial and/or pattern associated with this observation.
  10. Repeat steps 5-8 as necessary to complete the requested spatial pattern.
  11. Observation is complete. The SI and the FGS are transitioned into standby mode.

All JWST detectors use the up-the-ramp (MULTIACCUM) readout method, that reads and records the signal of individual pixels multiple times as it is accumulated during an exposure. This allows the recovery of discrete information on how the pixel charge/signal increases with time. Each exposure consists of some combination of frames, groups, resets and integrations. A group is the on-board average of one or multiple frames. A group is transferred to the solid-state recorder for downlinking to the ground. The time duration of each group depends on the instrument readout mode and readout pattern selected.

(The ground-based data processing software can then correct bias drifts using the reference pixels and use “up-the-ramp” processing algorithms to reject cosmic rays).

The type of on-board processing applied to the data is instrument dependent. The plan for NIRCam and NIRSpec is that multiple frames comprising a group are averaged together before they are compressed and stored on the SSR.

The Focal Plane Array Processors in the IC&DH electronics have the ability to combine and difference frames as they acquire the raw digitized detector data. For diagnostic purposes it will be possible to transmit full frames from any selected SCA to the SSR without any intermediate processing.

Processing for target acquisition, via FPAP boards:

A scenario that might be used for target locate is as follows:

1 Obtain two MULTIACCUM exposures, each comprised of a single group at the starting location.

2 Combine these, pixel by pixel, using the minimum flux of the two exposures to produce a new image. This processing removes cosmic rays.

3 Execute a small-angle maneuver of an integral number of pixels.

4 Obtain two more MULTIACCUM exposures, each comprised of a single group at the new location.

5 Combine these two images using the minimum flux method as before.

6 Register the two cleaned images using an integral pixel shift corresponding to their offset on the sky.

7 Combine the two cleaned, registered images using the minimum flux method. This eliminates hot pixels.

8 Determine the centroid of each reference object.

9 Convert this centroid into coordinates in the instrument’s reference frame.>

This processing is done in the FPAP boards then passed onto the spacecraft CTP for guidance.

The daily data volume capability required for JWST operations is 229 Gbits of compressed science data and 6.3 Gbits of engineering telemetry data transmitted to the ground at a nominal data rate of 28 mbps during a single contact .

Overhead required to packetize the data for downlink is assumed to be 2% for CCSDS packetization and 15% for Reed-Soloman error correction encoding, requiring a contact of about 3 hours including time required to retransmit packets with uncorrectable bit errors.

The Observatory plays back stored mission data when commanded by the Science and Operations Center. Science and engineering telemetry are stored on separate partitions on the solid state recorder in fixed file sizes (nominally 1 Gbit for science, 100 Mbit for engineering).
Critical engineering telemetry is stored on a separate partition. When a recorder playback is command, the critical engineering telemetry partition is downlinked first, the full files from the engineering data partition, and then full files from the science data partition. As files are filled on the engineering and science telemetry partitions, they are also downlinked until playback is halted.

As I say, its been difficult to find any hardware specs on the image processing side of the ICDH (Integrated Science Instrument Module & Command and Data Handling).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.