Hacker News new | past | comments | ask | show | jobs | submit login

Typically, but SpaceX has made rather a habit of ignoring expensive space-grade components in favour of consumer-grade ones they test themselves for a fraction of the cost. I guess we'll see.

SpaceX has made a habit of doing that only for their rockets, not telecommunications satellites, and only when it makes sense. Their biggest cost savings are in operations, manufacturing processes, and their engines because there really isn't much room to skimp on anything else.

Even at a cost of $10k per kg it makes very little sense to use 50% less efficient solar panels to save a few thousand, especially when the superior technology is also far better tested in space. It makes sense to use an Android instead of a $100k RAD hardened processor if your entire CubeSAT barely costs that much. Since most satellites cost a minimum of a million each, very few can afford the risk to save money on parts (and if you're mass producing thousands of them you can get really cheap germanium panels).

Cumulative Wh produced per sunlight/night cycle (remember these are in LEO and constantly passing in and out of the earth's shadow) per kilogram of solar panel is also important, when the satellites will be quite small.

You want the greatest possible power capability in the smallest and lightest package, and right now the way to do that is a triple or quadruple junction GaAs type PV cell with a concentrator lens in front of it. Efficiencies range from 32 to 40%, vs 22.5% efficiency for the very best monocrystalline Si PV cells.

This is all absolutely true - and would apply in any typical circumstance - but I'm not sure this is typical.

These aren't geostationary - they're low earth orbit. This means several things:

- cheap to launch - and to deorbit.

- lots of erosion compared to GEO - LEO is like being in a mild sandblaster while occasionally being shot at by rifles and howitzers.

Taking those two alone into account, you either end up building for durability or for disposability.

When you're dealing with a fleet of 4000 and your speciality/the thing you want to practice is heavy lift to LEO/MEO, you are absolutely talking about a disposable fleet where you expect daily failures and replacements. Having mass production facilities at your fingertips can't hurt.

Which is why they'd likely go for the cheaper tech that they have very low cost access to, even if it costs about the same after launch costs. Also, it would be more profitable for the collective enterprises than outsourcing such a component to a third party. Think about it - spend the money with a competitor, or at the gas station. I know which I'd do.

So - despite obvious truths re GaAs, my money is on them using their own Si cells.

I think you're vastly overestimating the significance of satellite material cost and underestimating how much larger assembly, testing, and operating costs are going to be. Four thousand satellites sounds like a lot and it is in the single unit volume world of aerospace, but it's not even close to enough to reach the kind of economy of scale everyone thinks about when they hear the phrase mass manufacturing. The cost of parts will be tiny compared to the cost of assembly and testing. To give you some perspective, you can get a 80mmx80mm 28% efficient GaAs solar cell for about $600 on Alibaba and the equivalent Si cell is about $6 with about 20% efficiency. At the volumes needed for a constellation of thousands, from a reputable vendor like Spectrolab, the price difference is in the 50-100x range so assuming a $1 Si cell the equivalent GaAs cell will cost $50.

Do you see how small the difference is in absolute terms? That means that only a few hours of labor per solar cell or 100g of launched payload mean the difference between a 50x and 1x difference. Two GaAs panels ($100) will requires tens of grams less support structure than the three Si panels producing the same power ($3) so already the extra launch cost (at $5k per kg, assuming free payload support structure) for the Si panels is eating away at their benefit. Each solar cell will need hours of inspection and testing by people paid $25+/hr so even if each extra Si cell and support structure costs nothing to launch, the final cost once fully assembled, installed, and tested will be in the range of $1k-10k per solar cell.

Especially at the scale of disposable satellites, GaAs is likely to be cheaper, more efficient, and free more volume and mass in the satellite design. 4000 satellites worth of Si solar cells would be the equivalent of a few dozen decent sized residential installs so it would be a drop in the bucket for SolarCity. I don't think keeping such small scale business in-house is much of an advantage, especially when there are many other suppliers with lots of experience in using solar cells in space.

>lots of erosion compared to GEO - LEO is like being in a mild sandblaster while occasionally being shot at by rifles and howitzers.

At 1100 km the debris population is relatively sparse. https://en.wikipedia.org/wiki/File:Spacedebris_upd_2011.jpg

But in lower parts of LEO you still have meaningful amounts of atmosphere(!).

Sure, you can use commercial parts in LEO for the processor. That is very common in the small satellite world already. But I really doubt they would run Android. Why not just bare Linux, possibly with the PREEMPT_RT patchset, or another RTOS? Especially since attitude control is a real-time problem.

I was just providing an illustrative example, the exact implementation details are irrelevant. Android phones have been used as the central processors for a number of CubeSAT missions so without any circuit design you can get a sub $500 CPU kit which is much faster and cheaper than a $100k RAD CPU (and available at any electronics store unlike single board CPU modules).

Telecom satellites already require tons of specialised integrated circuits because general purpose CPUs are too complex and power hungry for the amount of bandwidth the satellites process. This SpaceX constellation will certainly have custom designed electronics, even if they don't use any rad hardened ICs.

> Why not just bare Linux, possibly with the PREEMPT_RT patchset

That'd be a really bad idea. Linux is too complex to trust, and lacks WCET making it unsuitable for hard realtime.

There's open source options, but Linux isn't among them. I'd look at seL4 for this purpose.

SpaceX already runs Linux on their rockets; apparently near-real-time is good enough for that purpose.

Yes, I was saying why would you use Android instead of just bare Linux (as in Yocto). I doubt you will be writing an ADCS application in Java using a GUI.

Also, I think the Falcon 9 uses VxWorks for at least some of its realtime control: http://blogs.windriver.com/vxworks/2010/12/vxworks-helping-c...

http://lwn.net/Articles/540368/ doesn't mention VxWorks.

Looks like Dragon runs VxWorks, see under Flight Software.


Can anyone who works at SpaceX chime in?

That article also says

> One of the areas they focus on is scheduler performance. They do not have hard realtime requirements, but do care about wakeup latencies, he said.

It sounds like their hard real time controls are on non-Linux OSs.

Do SpaceX build telecommunications satellites?

Not yet. It's worth noting that the OneWeb constellation of small satellites is going to be produced in a new factory, because existing ones aren't set up for assembly-line production:



This means that existing companies that build telecom satellites need to do it a new way for these constellations of lots of small satellites.

>> Do SpaceX build telecommunications satellites?

They have a satellite division which has a bunch of people designing things, but they have not launched their own yet. They have also made known their intention of fielding a global internet service via a large constellation of satellites. This application would be a step toward that goal.

Question: whenever SpaceX launches a thing to the ISS - do they have an experimental payload along for the ride to "test some shit out"?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact