“Turn it off and back on”
(Presumably they’ve already tried that…on to step 2 then)
NASA has completed a formal review of what engineers will have to do to switch the Hubble Space Telescope to its backup hardware. The formal review comes more than a month after a problem with a payload computer aboard the veteran observatory sent the telescope into safe mode and engineers scurrying for contingency plans. …
I am sure they would not do that. The standard IT support advice does not work well in orbit. Its OK on the bench and might work but a lot of settings might need to be reset and loss of the spacecraft might occur. Notice how many mights were in that sentence? There are probably a few more unknowns that are unknown.
This has the potential to be all too familiar, only turned up to 11 – I'm not surprised they're carefully checking all possible scenarios. I've more than once found myself pressing Enter in an SSH session to a router only to realise my mistake a fraction of a second later as the connection is "unexpectedly closed" (yes, it is accepted that I'm an idiot). Difficult enough when it's three hundred miles away, even more so if the direction of those miles is up.
As I have said to people I work with, find an engineer who has never done any of the above and we have found either a liar or they have only worked in the field for a couple of weeks.
All of us have done this and the honest ones admit to doing it and will explain how they recovered from the problem.
There's also a need for intuition - which is not guesswork, but in the words of the late Robt. Ornstein "arrival at a correct answer without recourse to inference". It's based on accumulated experience but experience alone is only a part of it.
For example, in the days of dumb terminals, I was thrown a dead one to fix. A huge board covered with TTL chips, no manual and no circuit diagram. It suddenly occurred to me that TTL is tough stuff, so I raided the digital chip drawers in the electronics shop and, one at a time, I sat a replacement chip on each of the onboard devices and turned on. Half a dozen chip tests down the line the terminal sprang to life. So I turned off, replaced the said chip and everything was fine. I haven't a clue why that approach occurred to me - it's distinctly oddball, but it succeeded. That's intuition, and without it the terminal would have been scrap.
Had this during training once. All the machines had been left from the previous class and only a few bits were "reset". During the training I had something fail and would consistently fail. Most of the class left and there was the trainer, myself and one other person left. It took us around 2 hours to find and fix the problem, but it did reoccur a few times over the next few years with that app.
Without that course I would never have known
The trainer said he preferred to leave the machines this way instead of reimaging as a freshly imaged machine would not have these problems.....
It sounds corny, by mistakes are great learning experiences.
A quote from James Davis Nicoll(*) that turned up on tor.com a few days ago:
Nothing teaches one not to try to stamp out burning thermite quite like real-life experience.
(*) If you've never heard of him, the man's a first class accident magnet with the resulting collection of tales to match.
I'll take your bet - and your money. My father has never screwed up a firewall, rebooted the wrong router/server/disk array, or had remote hardware or software go into an unrecoverable loop.
But then he's a licenced aircraft engineer, not just an electron-botherer. ;-)
And I'm sorry, but I do not believe that he NEVER made a mistake on any production IT gear.
Yes, as time goes on, you certainly learn not to make stupid mistakes, and in highly-regulated, relatively static environments, it's much less likely you'll make a mistake, especially one that has a noticeable effect.
I'll even accept no mistakes that cause an outage - certainly possible in said highly-regulated and highly-redundant environments. I personally never had any downtime in Exchange while running it over 15 years, as one complex system I dealt with.
But never, ever any mistakes, from the beginning of his career? I'll have to take that with a big grain of salt, I'm afraid.
Guilty as charged. Did that from home to a router at work in London and found myself having to catch the Stansted Express early on Sunday morning. I figured it would at least be quiet but it was packed with sweaty journalists. I didn't find out until later that day that my router woes had been somewhat eclipsed by the news that Diana had died.
So I remembered that much, but did I learn anything? *cough*
Another repair mission is needed. I'd thinking a Dragon on Falcon Heavy could easily lift the necessary hardware and personnel to Hubble. The issue is reentry: Can Dragon take the higher reentry speeds?
If it can, then bring along new stabilization gyro's and a shortened Canada Arm to grab the satellite. Break out the shuttle space suites for on-orbit repairs while your at it.
A repair mission would be far preferable to the "NASA has a plan to send up a de-orbiting module that attaches to Hubble and drives it into orbital decay mode to allow it to be brought down into the ocean or on unpopulated land" mission that El-Reg reported a few years ago...
Could an astronaut wearing a EVA suit exit and enter the Dragon? Is there space to dress and undress the suit?
Gemini was designed to let astronauts get out with its two large "doors", and for astronauts wearing the suits.
Moreover a complete platform to catch the Hubble and keep it while astronauts can work around it with al the required tools and replacement parts available would have to be designed and build. And would need to fit an available rocket - people tend to forget how large the cargo bay of the Shuttle was.
There is a lot of space capabilities that have been lost with the Shuttle retirement.
Incredibly risky mission for the astronauts even with Shuttle, its multiple times riskier now, it's something Starship is probably more capable of than Dragon eventually,but I think youd struggle to even get through the hatch of Dragon in a shuttle style space suit to begin with. Let alone "capture" the telescope in a safe manner that astronauts on EVAs could work on it.
Look it's done 30+ years of service, it was only designed to do 15, if you compare it to ground based telescopes the costs/science actually Hubble is a poor choice now, but it's pretty pictures capture the public imagination so it gets cited way more often as delivering that special science dividend,when we are learning more about the universe from stuff sitting on tops of mountains.
Let them try to fix it if they cant just accept it's done its job and move on, the James Webb telescope though not a direct replacement by any means launches in October assuming ESA can resolve the cargo fairings issue.
Since they already have a working and debugged design that they have already manufactured, launched and operated once, can't they just make a new Hubble and launch it?
Note that I don't mean an "improved" design, I mean a straight copy but with the mirror shaped correctly this time. We know that an "improved" design is expensive and time consuming. We know that Hubble, as-is, is doing good science, but will fail soon.
I'm wondering how much a new Hubble would cost compared to the price of a servicing mission.
Well, they don't necessarily need to start from scratch...
NRO donated couple of Kennens to NASA
Plenty more articles on that around.
"Since they already have a working and debugged design that they have already manufactured, launched and operated once, can't they just make a new Hubble and launch it?"
Who is "they"? It was designed and built 30 years ago. Many of the companies involved in manufacturing will no longer exist, many of the people who actually did the design and build have likely retired, the plans on record are likely far from complete and in any case many things have changed since it was first built and there's virtually no chance all the designs for each bit are actually in the same place. There will be materials no longer used, components no longer available, processes now all completely different, and many, many other issues. Yes, in theory everything required should be properly documented and neatly filed away. In practice, that is never actually the case.
Once things get past a certain age, especially with a one-off project that used bespoke parts, it almost always ends up much easier to build something new from scratch rather than try to reproduce the same thing again. It's easier to design something that does the job you want that it is to design something identical to an existing thing.
>can't they just make a new Hubble and launch it?
Hubble was super-compromised by it's need to work with Shuttle, and be built from a KH-11 spy satelite. It's not what you would build today.
Arguably neither is JWST, if you assume launches are now relatively cheap and regular you might go for a production line of 2-3 year launch cycle with new instrument technology on a common bus.
For all it's whizzy space technology - the best thing Hubble did in terms of research/$ was the whole Space Telescope Science Institute, the IRAF software infrastructure, the data archive and the funding for post-docs.
It led to a much more efficient processing and publishing than typical astronomy of the time - although ground based has learned a lot from it.
Biting the hand that feeds IT © 1998–2021