Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> (my agenda, for transparency: I want to send SOC's in space on tiny RISC-V satellites, and the lowest layers of those should be 100% error-free because there's no going physically there to reboot a working shell, remote is all we have.)

Speaking from a bit of experience at Satellogic as well as folklore, trying to make the lowest levels 100% error-free isn't a good strategy. A better strategy is to make the lowest levels capable of recovering from the errors that will occur most frequently. Radiation is going to flip bits; processors are going to fail and sometimes hang; batteries are going to go low; temperatures are going to exceed specifications. If your system is built on the assumption that the lowest layers are going to be 100% error-free, you won't give sufficient attention to handling those errors when your assumption inevitably turns out to be wrong.

One suggestion: include a remotely-triggerable reset sequence in a hardware state machine. A 4-bit state machine driven by 4-bit symbols will work reliably if your channel error rate is small compared to one error per 16 symbols, and it has a false positive trigger rate of 5.4 × 10⁻²⁰. (This is of course vulnerable to malicious DoS attacks if a malicious party learns the 64-bit reset code, but in practice those have historically been an enormously smaller concern than satellites failing randomly in ways that a reset switch can correct.)

It's worth thinking through the fault tree of that reset mechanism. It needs to use omnidirectional antennas, for example, because otherwise it's dependent on attitude control. It needs to be on all the time, not just when you're passing over ground stations, because otherwise it depends on the clock and whatever kind of navigational system you have. It needs to be unencrypted, because otherwise it depends on your encryption protocol, which typically also involves clocks. It unavoidably depends on some kind of power source, but you can connect it directly to the solar panels and/or batteries, rather than through a switch. You probably want to use logic that can tolerate a fair bit of uncontrolled variation of the power supply voltage, not, say, TTL. But then you need like 4 flip-flops and a couple dozen gates. It can fail, but it's simple enough that you can make it highly reliable, unlike a RISC-V.

So, don't think in terms of making the bottom level 100% reliable. You won't get there. Think in terms of how to prevent inevitable unreliability from snowballing, how to make the satellite resilient against inevitable damage and malfunctions, as well as reducing that bottom-level unreliability to an absolute minimum.

As for blockchains, I think they're a very pragmatic solution to serious problems that are otherwise unsolvable: how can I send money to a friend in Venezuela? How can refugees carry their money safely without it being confiscated by pirates, corrupt police, or immigration authorities? How can people pay for illegal drugs without meeting in person with the vendors? How can we fund Wikileaks so they have the resources to transport Ed Snowden to safety? How can we fund Sci-Hub so that knowledge is available to everyone and not lost? Even international remittances to family members work enormously better with Bitcoin than with Western Union or SWIFT, particularly between countries with some degree of unfriendly relations.

It's a similar approach to that with satellites: we know there are bad actors in the financial system, and we want to engage in transactions with them, without giving them the opportunity to sell our credit card numbers to the Russian Mafia or take all our money. We want to prevent the small amounts of inevitable unreliability from snowballing and destroying the entire civilization. Also, we want to minimize the number of attempted ripoffs, so that our defenses against them can be less costly. It turns out that thieves, unlike cosmic rays, respond to incentives, so by making thefts more difficult to pull off, we can also decrease the number of attempted thefts.

Obviously I don't trust Facebook to design the world financial system, though. They elected Trump.



Thanks so much for all the food for thought and recommendations. I had a hunch for "capable of recovering", and now I have a clearer roadmap (some critical steps). I see your way of thinking. This in particular:

> Think in terms of how to prevent inevitable unreliability from snowballing, how to make the satellite resilient against inevitable damage and malfunctions, as well as reducing that bottom-level unreliability to an absolute minimum.

High-availability of components seems like a given to me (e.g. have 2, 3, 4 batteries as distant from each other as possible, to mitigate loss if one gets shot by some collision or outright fails; rinse and repeat for every critical component, starting at circuit design). In another comment, user "pjc50" suggests to me “"lockstep" chips, such as TI Hercules”, and yet my intuition would be to put two redundant ones on each satellite, just for good measure.

But the ultimate economics of the project can be made to work, imho, because I envision a swarm of such tiny satellites actually, wherein you can afford to lose a few nodes now and then, if that makes all of them orders of magnitude cheaper — and thus you can send orders of magnitude more, overall. Brute-force the reliability issue by making them expendable to a reasonable degree. No human life means they can die for all we care, if it makes sense cost-wise. Hence why in that perspective, a discussion on the cost versus benefit of formal methods is of great interest.

Needless to say, any advanced draft of the project would inevitably have to be vetted by, actually co-developed with field experts like you. To each contributor their domain. I hope it will be a given too, since I'm thinking of a 100% open-source project (both software and hardware ideally). The more eyeballs...

____

I see your points about blockchain, and they make a lot of sense; the problem I see with current 'cryptos' in general (including the big one) is that they simply aren't welcomed by most decisive institutions, including those who combat on principle the problems you mention. Like, you see the EFF et. al defending e.g. E2E encryption, but none of that drive to promote bitcoin.

Thus that 'respectable' cryptocurrencies exist to solve these problems, sure, please, yesterday! — but that they reform the financial system by their very existence? There doesn't seem to be much appeal in the mainstream. I think it's a matter of time, how much each generation weighs demographically in the global opinion / decision power. For now, it's boomers, and they're not in that place.


I'm not a field expert; I didn't design Satellogic's satellites.

Satellogic's CubeBug design did use a TI Hercules TMS570 Cortex-R, and I think it's safe to say our experiences with chips like that were good — for the relatively restricted tasks they can perform. The automotive industry has a lot of lockstep chips available for it, because it's a mass market that demands reliability under harsh conditions.

I'd like to point out that what you're describing is pretty similar to Satellogic's original business plan.




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

Search: