JWST Solid State Recorder | Hacker News Reader

JWST Solid State Recorder

jwst-docs.stsci.edu

115 pointsorzi39 comments

I am sure there are better presentations out there, but this conference proceedings has some great pictures of the control systems in JWST [1]

I was also able to find a high resolution picture of the spacewire interface card with its glorious space grade asic packages [2]

Sadly the SSR is not shown, I assume that it is basically a gigantic sheet of sram and a fpga.

[1] https://www.researchgate.net/publication/233962152_Status_of...

[2] https://www.nasa.gov/vision/universe/watchtheskies/jwst_spac...

> The JWST ICDH team delivered the SpaceWire technology – which is packaged in a digital, low power (1.5W), high speed (66Mbps) Field-Programmable Gate Array (FPGA) computer chip

The concepts of "low power" and "high speed" has changed a lot since JWST was designed.

I think you're forgetting to factor in the distance.

Say, a low-power, high-speed interface which is USB 3.2 only works via good copper cables and at distances of a few meters.

Indeed.Given that the design process started almost 25 years ago, I'd be more surprised if it had changed less than it has.

In [2], especially on the second picture z you can see some solder joints are not consistent or perfect: convex rather than concave fillets and differing amounts of solder.

Now of course it still looks better than most commercial PCBs and far ahead of anything I ever made. But I was expecting a board flying to space to be "perfect", touched up by a gray haired wizard.

How come? Is this actually plenty good, do they cover this in so much conformal coating there is no chance of joint breaking due to vibration and thermal cycling, or what?

Btw the large square packages in the first picture look amazing.

These electronics tend to be hand soldered so there is less uniformity than reflow.

I looked at both boards in detail and I highly doubt they were hand soldered.

Finished modules or even whole spacecraft are tested in giant ovens to make sure there are no issues with heat.

https://m.youtube.com/watch?v=5MG9Lof1m_o

> ... JWST will downlink data in 4-hour contacts... In one contact, JWST can transmit at least 28.6 Gbytes

This works out to 2 MB/s.

Surprisingly high IMO

I know people who live within 30 minutes of me who get less than that - and I live in a college town.

They didn't have a 70m sized parabolic dish, though.

They don't, that is true.

It's just highly impressive to me what we're able to accomplish when we actually focus effort on a task - including getting high-ish bandwidth back and forth between something in space.

Considering that's 2MB/s upload, I get less than that and I live in a major city with a major ISP.

The DSN can receive data from MRO at Mars at up to 4 megabits per second, apparently. JWST is way closer, so it should be quite a bit faster.

How does this storage hold up over time?

I'm guessing that could be one of the limiting hardware elements. There must be some redundancy in that right?

Given the capacity, I would be surprised if it wasn't single-level cell NAND (larger write capacity) or redundant. From articles I could find, it was installed in the JWST in 2012[1] and developed by a company called SEAKR which produces "Solid State Recorders"[2]. Certainly doesn't look like any commercial server storage I've seen.

I imagine the contracts could be FOIAed here and specs like anticipated write capacity obtained, would be very interesting to learn about radiation hardening and redundancy for SSDs - err, solid state recorders - in space.

[1] https://www.electronicsweekly.com/news/business/information-... [2] https://www.seakr.com/our-technology/#products

> From articles I could find, it was installed in the JWST in 2012

I suspected something like that. I assumed there was a reason there was "only" 65GB of storage up there, when I can get a half terabyte microSD card for under $70 on PrimeDay. Lots of Moore's Law has happened in the last 10 years...

As a RaspberryPi enthusiast, I'm under no illusions about the reliability of microSD cards, but I wonder whether if they were building that data recorder today, that a huge raid 1 with perhaps 20 or 50 mirrors stored on 512GB SD cards might be able to compete on reliability and cost (including launch weight)?

Bit flip probability is inversely proportional to density of the storage media so denser might have you run into issues. Also theres no point on building a recorder that's 10x larger than what you need if you're going to be limited by downlink availability. You could probably get away with all those SD cards in LEO though for a short missions, JWST falls into the category of missions where the price of that storage medium is going to be a rounding error vs the price it would incur if it randomly failed during qualification.

It would still be better to have 10-100x in enterprise-grade storage with, say, quadruple redundancy. As Ingenuity has shown.

> As Ingenuity has shown.

Bad comparison - Ingenuity was spec'd for five 90 seconds flights [1], JWST for up to ten years, depending on how much they have to use its rocket engines.

[1] https://en.wikipedia.org/wiki/Ingenuity_(helicopter)

[2] https://www.americanscientist.org/article/jwsts-limiting-fac...

Another reason for the 65GB of storage is that storage is only used to buffer a day worth of transmitted data along with the previous days data till reception is confirmed.

> https://www.seakr.com/wp-content/uploads/2016/08/Flash_FMC-G...

Looks like any other SSD from a few years ago, just bigger and in a metal box.

> The GEN3 FMC is a 192 GByte card designed for space applications. It is a standard 6U cPCI form factor composed of 3 cards: the main controller card and two memory mezzanine cards. It supports data and control transfers via the backplane cPCI bus.

That's just a flash card. It's not the solid state recorder.

From the previously-posted IEEE article:

68-GB solid-state drive [...] by the end of JWST’s 10-year mission life, they expect to be down to about 60 GB because of deep-space radiation and wear and tear.

https://news.ycombinator.com/item?id=32067945

https://spectrum.ieee.org/james-webb-telescope-communication...

Reading this stuff always makes me wish I did real computer stuff.

I feel this. As a first year Computer Science student at university I am currently torn between staying as CS or switching to Computer Engineering. I am really interested in the low level aspects of computers from a software perspective (OS development, assembly, compilers) but I feel my education in my area of interest won’t be complete if I don’t also understand things from a hardware perspective.

Alas, most of us are cursed to build CRUD applications in either old but reliable tech or the latest and greatest, which will be replaced with the next latest greatest in ~5 years when the next generation of over-excited devs rocks up. Sigh.

Why don't you? 10 years ago I was getting tired of working on php crud apps, revived my electronics hobby, practiced on small contracting jobs, landed an interesting embedded software position which then lead to my current position job at a drone company. I had to pick up some new hobbies though, after I made a job out of my hobby- maybe that's what you're afraid of? :)

Mostly money. It’s not a popular answer but doing what I do I make nearly 500% more than doing what I miss doing. I’ve got family and future to save for, and I can get to my goals faster doing this stuff. The upside is that I might be able to “retire” in a few years, which to my mind is doing what you want to do regardless of the compensation. So we will see :-) I may just join you soon.

> If a contact is missed, science observations can continue without filling the recorder, and the ground can catch up on the next contact.

Total noob question but how exactly does this part work? It seems like if you record close to the 4h transmission limit of data between contacts it wouldn't be possible to catch up on next contacts and not fill up the recorder. Is it not possible to record that much data in the timeframe between contacts, or is there some safety margin in the transmission limit they state for this reason?

That's assuming they get close to the contact transfer limit. A lot of theoretical numbers are stated. Now that it's in use, maybe we'll get some practical numbers. Perhaps they never will get near the contact data limit, so it's not to be a concern.

It's possible they don't "catch up" for a while, getting a few extra bits and pieces over the next several contacts, not just at the contact following that missed.

One of the interesting things about this is all the tooling created around the JWST. Like there is even a downloadable app that you use to plan & book time. Plus all the documentation, etc.

Some of the software are made available here:

https://github.com/spacetelescope

The Physical Optics Propagation in PYthon (Poppy) has some neat pictures: https://poppy-optics.readthedocs.io/en/latest/

This would be really cool to plan out a look at a specific galaxy or something to personally study if its not already on another queue

The Cycle 2 General Observer proposal deadline will probably be late this year or early next year (I forget exactly when). Anyone can apply, and proposals are reviewed by scientific panels after submission.

The Cycle 1 documentation, including the now-expired Call for Proposals is here: https://jwst-docs.stsci.edu/jwst-opportunities-and-policies

> Like there is even a downloadable app that you use to plan & book time

If you mean the APT (Astronomer's Proposal Tool) this tool was originally developed for Hubble Space Telescope proposals, and has been in use since at least least 2008[0]. A year or two ago, I found that parts of it are written in Common Lisp[1].

[0] https://www.stsci.edu/scientific-community/software/astronom...

[1] https://apst.stsci.edu/apt/documents/documentation/apt-proje...

Seems likely. Decades ago I had a discussion with someone about working at STSI, and the draw for me was that I would be working in CL.

Nice!!! It would be interesting to read more about shielding from radiation, data protection mechanisms, redundancy, MTBF and all the rest.

Reply on news.ycombinator.com