[topherhaddad]

Moving fast to make launch, we had missed a harness checkout step that would’ve caught a missing comms connection into an FPGA, and it was masked because our redundant comms channel made everything look nominal.

On orbit, we fixed it by pushing an FPGA update and adding software-level switching between the channels to prove the update applied and isolate the hardware path — which worked. Broader lesson, it is possible to design a sw stack capable of making updates to traditionally burned-in components.

[roughly]

> it was masked because our redundant comms channel made everything look nominal.

Hah, this has bitten me often enough I check for it in test suites now - ok, you’ve proven the system works and the backup works, have you proven the primary works? Another in the long list of ways you don’t expect a system to bite you until it does…

[moffkalast]

That's why starfleet always has a secondary backup /s

[arter45]

>On orbit, we fixed it by pushing an FPGA update

How does that work? Do you actually VPN into an orbiting satellite? If so, how do you get a public IP for a satellite? Do you just ask an average ISP?

[fc417fc802]

Why would you need a public IP? Why would you want to expose something like this to the public internet?

I have no idea what they use but there are various commonly used radio communication methods for talking to satellites.

[czbond]

> it is possible to design a sw stack capable of making updates to traditionally burned-in components.

This is interesting - is the software stack essentially acting as "light" translation layer or abstraction layer on components?