Hacker News Reader

Comment by shanxS | Hacker News Reader

Apart from science experiments and taking pictures, how can this platform be used to deliver business value?

There is a number of applications in development that will rely on in-space processing. Such as forest fire prediction, business intelligence from space (estimate the crop yields, oil reservoir levels, city planning and so on). Most of them use ML algorithms to extract valuable insights.

Is bandwidth from outer space so expensive that you save money by moving compute to the edge and only pushing down results to earth instead of the entire data set?

The bandwidth is not expensive. There is simply a lack of it.

Most LEO satellites have 10-20 minutes a day communications window assuming single ground station. Amount of data you can download from a single pass is a tens or hundreds megabytes per day. One high-resolution camera image can be easily over 10MB.

Very interesting, thanks for the follow up.

Would this issue be any way relieved with things like AWS ground station?

If you can only see a ground station from a satellite for 20 minutes, could you just add more ground stations?

Or is that 20 minutes window constrained by something other than having a ground station within receiving range?

More ground stations will definitely make things better, but 24/7 connectivity to assets in LEO will take monumental, Starlink-scale level of effort.

Would it be possible to use Starlink for comms if a sat is flying in a lower position?

In theory, yes.

In practice, this will depend more on my negotiation skills when talking to Elon Musk and less on any technical challenge :)

No, it will not be possible, no matter what Elon says.

Starlink operates in portions of the Ku and Ka bands that are reserved for Earth-to-space comms, not for space-to-space comms.

My impression was that Starlink relies on inter-satellite links to route traffic. We can use the same links for our own extended network.

The current satellites do not have crosslinks, and in any case, in their FCC filings SpaceX talks about optical crosslinks, not RF.

You can get 24/7 connectivity to LEO right now (and 25 years ago too) using TDRSS.

The system costs a fraction of what Starlink will cost, as you only need 3 GEO satellites.

There is plenty of bandwidth to achieve more than 1 Gbps of throughput from a 3-U cubesat (see Planet with their latest X-band comms-system [1], which results in more than 50 GB per pass). If you really need more than that, new free space optical communications systems under-development will bring multi-Gbps to small-sats [2]. For me, the real problem with nanosats is that they generate barely no power and they are really volume-constrained compared to the bigger birds (so you cannot have high-resolution sensors, and cannot fit in there a good optical-comms system, you need to be mindful of your power consumption all time during the mission...).

Finally, note that nowadays Planet downloads 10 TB/day, and they could go up to 40 TB/day once they upgrade their fleet with the latest X-band antenna, which is comparable to the 80 TB/day that DigitalGlobe generates.

[1] https://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=4... [2] https://www.tesat.de/images/tesat/products/TOSIRIS_Data-Shee...

I remain skeptical as to the broad applicability of this approach. Some amount of preprocessing on on the space segment is valuable for certain mission types, but I don't know how generalizable it is.

By doing all your processing on the space segment you have eliminated the possibility for analysts to take the level zero / level one products and reprocess them manually, either for quality assurance purposes or to develop enhanced or entirely new capabilities with the data.

The other main problem I have with satellite-as-a-service type approaches is that it requires building generic spacecraft hardware by necessity, which means that you'll never be optimized for a particular mission type. When you build a mission from scratch, you get to carefully specify sensor parameters to achieve your remote sensing objective. Not so much when you're trying to build a generic bird that does everything. For most applications that benefit from generic data, what's the advantage over, say, downloading data from Copernicus (which already has pole to pole coverage at moderate resolution and revisit) or tasking a DigitalGlobe satellite to do the work?

I can think of some edge cases where realtime calls might be valuable (eg: dynamic re-tasking based on realtime image analysis, especially if you have a wide-view forward squinted sensor and a higher resolution nadir sensor), but I really don't see the broad applicability.

It's true that communications is definitely a bottleneck in high resolution wide-coverage missions, but there are other intermediate approaches that work before going all the way to doing the entirety of the processing including decisionmaking on the space segment. We have a lot of room to grow in the comms space, such as moving EO missions to Ka-band (and above) and free-space laser for missions without stringent data latency requirements. Sure, it's a crowded world if you're doing X-band from an isoflux antenna, but there's other architectural options to improve throughout. We can also look at doing selective preprocessing on the space segment (ie: up to Level 1 products) which may allow for better data compression.

I'm not saying there isn't room for space segment processing and dynamic tasking - I saw a really interesting mission proposal a while back that used it extensively. But I don't see the business case for it on generic satellites in all but particularly niche cases.

Well, that deserves a reply beyond the HN comment format. ESA hosted an event, called Phi Week, presenting many possible application cases in Earth Observation domain: https://livestream.com/esa/phiweek2020

If you don’t want to filter through 20 hours of videos, drop me an email to contact@exodusorbitals.com, I can send you a written summary. And some documents on our platform capabilities.

Reply on news.ycombinator.com