Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
* [Starlink] risc-v in space
@ 2022-09-06 19:19 Dave Taht
  2022-09-06 19:51 ` Bruce Perens
  2022-09-07  4:30 ` Bruce Perens
  0 siblings, 2 replies; 4+ messages in thread
From: Dave Taht @ 2022-09-06 19:19 UTC (permalink / raw)
  To: Dave Taht via Starlink

A bit long on marketing, but

https://www.sifive.com/press/nasa-selects-sifive-and-makes-risc-v-the-go-to-ecosystem

Not a lot of chips in this market but I would love to see design tools
that could output robust fpga designs in particular.

The larger question I have though, is how much do we know now about
rad-hardening electronics in space?

I have a few tidbits I've picked up or there about fpgas, f-rams, and
so on, and was passively involved in a innovative
cubesat that did work (with 3 virtualized cpus) in an era where
cubesats had about a 50% failure rate.

and of course we see astronauts using COTS laptops. Is there a NASA
parts catalog of parts that just work and of those that just don't?

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Starlink] risc-v in space
  2022-09-06 19:19 [Starlink] risc-v in space Dave Taht
@ 2022-09-06 19:51 ` Bruce Perens
  2022-09-06 22:41   ` Vint Cerf
  2022-09-07  4:30 ` Bruce Perens
  1 sibling, 1 reply; 4+ messages in thread
From: Bruce Perens @ 2022-09-06 19:51 UTC (permalink / raw)
  To: Dave Taht; +Cc: Dave Taht via Starlink

[-- Attachment #1: Type: text/plain, Size: 2545 bytes --]

>
> The larger question I have though, is how much do we know now about
> rad-hardening electronics in space?
>
I've learned some.

Not quite related to that, but if you want to run an Open Source Space
project in the US without running afoul of ITAR and EAR, I can tell you
how. The policy I created was approved by Department of State and
Department of Commerce.

Here is a simple explanation for the uninitiated:

This is less severe for LEO because the satellites don't traverse the van
Allen belts. But the coronal mass ejections we are having just now and
their associated electrical effects could make the situation worse whatever
orbit you are in.

The largest problem we have is that radiation can trigger a junction to
conduct. If you have built your chip on a semiconductor substrate, that
means that some random chip feature can start conducting to the substrate
and latch that way until power is removed. Overcurrent can blow details
right off of the chip. So, you must build your chip on an insulating
substrate. This used to be silicon on sapphire, which was incredibly
expensive. Silicon on insulator does the job. It happens that many common
FPGAs are built on insulator, so that is a cheap way to get space-robust
processing.

Second issue is that you can get random triggering of junctions. This means
that chips can do the unexpected, and you need redundancy on-chip or off,
and a way to power off the chip because sometimes nothing else will reset
it. You also need error-correction on your memory, and a process that
continually "washes" your memory by reading it, and writing the corrected
data.

It doesn't work to shield your electronics with some dense material like
lead. The problem is that a high-energy particle can hit that and turn into
lots of lower-energy particles that are actually more harmful. So, a thick
enough shield to stop all of these secondary emissions is usually not
practical.

If you have enough money, you can pay a company like Vorago for a
space-qualified processor. It's pin-compatible with a non-space version of
the same CPU, so you can test it cheaply.

and of course we see astronauts using COTS laptops.


Those laptops aren't mission-critical. The risk to the astronauts is
probably a worse problem, for missions that traverse the van Allen belts.
Apollo used the location of a low-energy region, and got through there
quickly. Interplanetary missions are probably going to require lots of
water around the place where the people stay when there's a solar flare.

    Thanks

    Bruce

[-- Attachment #2: Type: text/html, Size: 3227 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Starlink] risc-v in space
  2022-09-06 19:51 ` Bruce Perens
@ 2022-09-06 22:41   ` Vint Cerf
  0 siblings, 0 replies; 4+ messages in thread
From: Vint Cerf @ 2022-09-06 22:41 UTC (permalink / raw)
  To: Bruce Perens; +Cc: Dave Taht, Dave Taht via Starlink


[-- Attachment #1.1: Type: text/plain, Size: 3119 bytes --]

ok to share with non-list colleagues?

v


On Tue, Sep 6, 2022 at 3:51 PM Bruce Perens via Starlink <
starlink@lists.bufferbloat.net> wrote:

>
>
>> The larger question I have though, is how much do we know now about
>> rad-hardening electronics in space?
>>
> I've learned some.
>
> Not quite related to that, but if you want to run an Open Source Space
> project in the US without running afoul of ITAR and EAR, I can tell you
> how. The policy I created was approved by Department of State and
> Department of Commerce.
>
> Here is a simple explanation for the uninitiated:
>
> This is less severe for LEO because the satellites don't traverse the van
> Allen belts. But the coronal mass ejections we are having just now and
> their associated electrical effects could make the situation worse whatever
> orbit you are in.
>
> The largest problem we have is that radiation can trigger a junction to
> conduct. If you have built your chip on a semiconductor substrate, that
> means that some random chip feature can start conducting to the substrate
> and latch that way until power is removed. Overcurrent can blow details
> right off of the chip. So, you must build your chip on an insulating
> substrate. This used to be silicon on sapphire, which was incredibly
> expensive. Silicon on insulator does the job. It happens that many common
> FPGAs are built on insulator, so that is a cheap way to get space-robust
> processing.
>
> Second issue is that you can get random triggering of junctions. This
> means that chips can do the unexpected, and you need redundancy on-chip or
> off, and a way to power off the chip because sometimes nothing else will
> reset it. You also need error-correction on your memory, and a process that
> continually "washes" your memory by reading it, and writing the corrected
> data.
>
> It doesn't work to shield your electronics with some dense material like
> lead. The problem is that a high-energy particle can hit that and turn into
> lots of lower-energy particles that are actually more harmful. So, a thick
> enough shield to stop all of these secondary emissions is usually not
> practical.
>
> If you have enough money, you can pay a company like Vorago for a
> space-qualified processor. It's pin-compatible with a non-space version of
> the same CPU, so you can test it cheaply.
>
> and of course we see astronauts using COTS laptops.
>
>
> Those laptops aren't mission-critical. The risk to the astronauts is
> probably a worse problem, for missions that traverse the van Allen belts.
> Apollo used the location of a low-energy region, and got through there
> quickly. Interplanetary missions are probably going to require lots of
> water around the place where the people stay when there's a solar flare.
>
>     Thanks
>
>     Bruce
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice

[-- Attachment #1.2: Type: text/html, Size: 4482 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3995 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Starlink] risc-v in space
  2022-09-06 19:19 [Starlink] risc-v in space Dave Taht
  2022-09-06 19:51 ` Bruce Perens
@ 2022-09-07  4:30 ` Bruce Perens
  1 sibling, 0 replies; 4+ messages in thread
From: Bruce Perens @ 2022-09-07  4:30 UTC (permalink / raw)
  To: Dave Taht; +Cc: Dave Taht via Starlink

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

On Tue, Sep 6, 2022 at 12:19 PM Dave Taht via Starlink <
starlink@lists.bufferbloat.net> wrote:

> in an era where cubesats had about a 50% failure rate.


Phil Karn KA9Q felt that this was mostly because of a poor choice of data
link. I think a lot of folks were using AX-25 packet radio, which wasn't
intended for satellites. He wrote a modem called BPSK1000 which can
tolerate 1-minute fades as a satellite tumbles and the antenna points away
from Earth.

    Thanks

    Bruce
-- 
Bruce Perens K6BP

[-- Attachment #2: Type: text/html, Size: 995 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-09-07  4:30 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-06 19:19 [Starlink] risc-v in space Dave Taht
2022-09-06 19:51 ` Bruce Perens
2022-09-06 22:41   ` Vint Cerf
2022-09-07  4:30 ` Bruce Perens

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox