Hacker News Reader

> Maybe you could program the software to notice that it hasn't gotten commands for a while and deliberately rotate itself into an orientation that causes a power loss and reset?

heh, some spacecraft buses are designed to do the opposite. they'll go into a spin during emergencies just to guarantee that their solar panels are hit at least occasionally.

> I'm guessing that the solar panels are arranged in such a way that it wouldn't work,

plenty of spacecraft have solar panel arrangements where it is possible for them to not receive any light.

> and the attitude control fuel consumption might be excessive.

spacecraft can (if designed to include them, which is common AFAIK) control their orientation with reaction wheels, no propellent required. (the reaction wheels will become saturated sooner or later, though. when orbiting bodies with significant magnetic fields they can be desaturated through the use of magnetic torquer bars. otherwise they have to use propellent to do it.)

Right. I was imagining the reaction wheel unloading using the propellant. But I don't know anything about this particular design, so the concern may or may not apply.

Simply turning around won’t put any long-term load on the reaction wheels though - you spin up to start reorient the satellite and then spin back down once you’re in the desired orientation. It’d be slow - reaction wheels aren’t really designed for gross maneuvers like this - but this is hardly an urgent situation.

It's the spin up and spin down that actually make the orientation changes, though. You can't spin up infinitely, so once a reaction wheel is spinning as fast as it can, you can't accelerate it further, and you can't rotate the spacecraft in the opposite direction on that axis any longer.

(I don't think reaction wheels are capable of gross orientation changes at all -- only very minor alignment corrections.)

> It's the spin up and spin down that actually make the orientation changes, though. You can't spin up infinitely, so once a reaction wheel is spinning as fast as it can, you can't accelerate it further, and you can't rotate the spacecraft in the opposite direction on that axis any longer.

precisely. angular momentum.

> I don't think reaction wheels are capable of gross orientation changes at all -- only very minor alignment corrections.

nah. as an example, SORCE has nothing but wheels and a torquer bar (or two?), and aims all over the sky.

The article's author figures that there was no such reset during the first eclipse following the failure (in 2007), but perhaps the batteries have now degraded to the point where they are drained during an eclipse?

Would it be possible to script a regularly recurring event to run everything on overdrive so as to put sufficient load on the on board battery to guarantee a low voltage event?

> basically, waiting for orbital geometry to turn the whole thing off and on again.

NASA calls Dell Support, too?

"Have you tried turning it off and on again?"

Far too many times.

There are actually products that do this kind of power cycling. I'm a happy user of a ResetPlug that fixes my WiFi problems by rebooting the router when the connection is down.

(I don't mean this as a spammy ad, just in case other people have as terrible Internet access as Chunghwa is giving me)

TBH you probably need a better WiFi router, not some external device that turns it off and on for you... Can you not at least schedule reboots of your current router? That silly plug is $60! You could have bought a mikrotik wifi router for cheaper than that...

The router is provided by the landlord, who already called out the service people from Chunghwa Telecom to look at it.

They turned it off and on again, and it worked (of course). So they refused to replace it.

And I can't schedule reboots, because it usually fails a few minutes after I start using it when I return to my house (not at a consistent time every day).

Ah that's a bummer. It's a modem/router-combo then. I've never had good experiences with the ISP provided ones...

You should be able to buy your own wifi router and plug it into your router/modem combo. Ideally, you'd then run the combo in bridge mode, but it should work regardless.

should and can, are not the same thing.

Why in the world would is that something you shouldn't do?

>you probably need a better WiFi router. That's the right answer. Last time I rebooted a router or AP: never. Unless there's a power failure they run years on end without intervention (DD-WRT on a Buffalo AP, DD-WRT on Netgear WNR3500's, and a number of managed HP MSM422 & Ubiquiti APs if you are curious).

I think restarting after a single pass through the program is a fairly common technique in real-time systems - I think the computers on the Lunar Modules worked this way. It means that you start from a known state on each iteration, and a further refinement is to allow only forward branches (so 'if', but no loops).

Yup, the aerospace data acquisition system that I've used works this way - each acquisition cycle finishes by resetting the FPGA and coming up from a blank slate.

I shouldn't admit it, but I have some tricky memory leak in a node.js server for my app - I spent an evening trying to find it, but in the end I just added daily restart of an app to cron, and it works beautifully ever since :).

Shouldn't admit it? It's my most recent blog post!

http://designbymobi.us/turn-it-off-and-on-again/

Wonder if the power display computer might be susceptible to Meltdown, Spectre or Rowhammer? Or is it not programmable in the sense that everything is hardwired…

Not susceptible to the first two because these are almost universally large-process in-order CPUs. But generally "not programmable" in the sense of being hard-wired, or just not having a way of doing remote code execution to perform the update. These systems are _really_ simple.

CPUs used in space are usually much simpler and slower than ours – they put enormous amount of resources on error correction due to radiation levels.

I suspect the CPU in this satellite is a BAE Systems RAD6000, commonly used in NASA spacecrafts. It’s extremely expensive and also brittle due to the materials used. Very hard to get due to export regulations. I tried to source one of these CPU’s outside US once.

Wikipedia at least confirms that.

Do you mean brittle in the physical sense, like a potato chip? That's surprising; I assumed that a launch subjects all components to a fair bit of shaking around, not to mention the steday G forces.

If that's the case, it looks like the chip has a surprisingly modern feature set. For example, based on this article[1], the RSC on which the RAD6000 was based had an on-chip memory controller in 1992.

It also had a branch predictor, however, this line is notable:

> Note that the RSC never speculatively executes prefetched instructions.

This means that the branch predictor only did fetch/decode, and so the chip would not have been susceptible to Spectre, as the pipeline would have been flushed and the correct instructions reloaded as soon as the condition evaluated false, before the branch would have been actually executed.

[1]https://web.archive.org/web/20131004213712/http://zmoore.net...

Meanwhile, in February 2000, at the Intel Developer's Forum, Intel demonstrates an upcoming 32-bit processor, code-named Willamette, running at 1.5 GHz.

That was the Pentium 4 not yet in existence so there is no chance of there being an x86 able to be 'Meltdowned' in space. However you are most definitely thinking along the right lines, but I am sure the NASA boffins would have tried all the hacks they could back in 2007. Or maybe the management made sure this was not possible, much like how the Voyager missions were not supposed to go beyond Saturn yet behind the backs on management everyone made sure those spacecraft could get past the edge of the heliosphere.

Why would it matter? It's not like it's running any untrusted code.

I believe the suggestion was that NASA could update the main computer with their own 'untrusted' to exploit the flaw in the power system, side stepping their own protections. But as mentioned below in other comments, these vulns are likely not present on this hardware

That doesn't make sense to me, aren't we talking about two different pieces of hardware talking together? If they could reflash the "display computer" then the problem would be solved if I understand correctly.

Even if it's really two "applications" running on the same CPU I don't see how spectre/meltdown would help since it's all about getting read-only access to "forbidden" memory. Clearly they don't need that (they know full well what's in memory), they want to be able to modify it.

In such a situation RowHammer might be used to modify the state of an other program sharing the same RAM in the right conditions but if there's one piece of hardware I expect to be hardened against spurious bitflips it's a space probe. We're talking about radiation-hardened ECC-protected RAM after all.