Astranis emerges from stealth with new satellite tech for connecting the world
techcrunch.com
techcrunch.com
https://en.wikipedia.org/wiki/Timeline_of_spaceflight
Also notable is the fact that of the 22 launches this year, three have been the debuts of entirely new vehicles, two of which were entirely privately funded. There are likely to be several more private launch vehicle debuts this year.
This is a really significant shift for what had long been a moribund industry, and a lot of complementary innovations will be able to piggyback onto this momentum.
If you think there is a rural/urban problem with optic fiber, you are jumping from the frying pan to the fire with LEO satellite constellations.
That's because an LEO satellite constellation has to cover the whole world (or almost all of it) to be able to cover any inhabited area at all. Thus it has to cover oceans, large roadless areas, deserts, mountains, etc. At least with optic fiber you only have to cover roads.
Note that high density areas can cause trouble on the other side -- you need to support the highest density worldwide that you support anywhere. Note that users in a place like New York City will generate noise affecting satellites 1000+ miles away, so if you don't ban people setting up accounts in dense areas, it will have to be priced so high that people with a lot of money looking for a backup connection will be priced out.
I am highly skeptical that the economics can work out for an LEO constellation.
The small-aperture terminal market has been driven by GEO satellites getting bigger, a lot bigger. Yes, we can fit more satellite in a small package, and solar cells have gotten more efficient, but there are laws-of-physics issues involving the size of the antenna, power requirements, etc. that aren't going to go away.
Geosynchronous satellite spacing is determined by the ability of ground stations to resolve satellites so there is a certain number of satellites that can fly, so there is a pressure towards large high-performance satellites that can deliver the maximum capacity as opposed to launching fewer low-performance satellites. Already the high-capacity satellites have insufficient bandwidth to serve demand (otherwise people would just be getting satellite instead of asking for terrestrial internet) and I don't see how low-capacity satellites will actually help.
I see similar problem with the terminals for systems like the SpaceX constellation. To get "wireless equivalent" performance I see the ground terminal requiring some kind of electronically scanned array which would put the cost upwards of $6000.
There is a precedent for satellite services with a high-cost terminal, as back in the 1980s many people would spend about that much for an unlicensed satellite terminal to receive TV, but since that was pirate there was no subscription fee. Compare that to $100 a month for cable and that pays for itself in 5 years.
I have this funny feeling that next-gen satellite providers want to have the expensive terminal AND the expensive service -- possibly because of the "Juicero" issue that the people bankrolling them don't know what prices look like to the average customer.
I would love it if you could prove me wrong.
The high capacity satellites do have insufficient bandwidth to serve demand, on that I agree. But that's not a spectrum limitation, its a limitation on how many such large GEO's have been launched. Which is a small number because each one is so expensive. There is still plenty more spectrum we can use for GEO telecoms, and more with proper frequency re-use schemes.
The point you make about the drive to large GEO's holds true if you assume only one spacecraft will ever be in a single orbital slot. But that's not the case. There's plenty of orbital slots where multiple GEOs are co-located, and this will increasingly be the case in the future. I'd argue the drive to large satellites was more driven by various incentives and systemic issues in the industry that drove them that direction. A much longer conversation, but it's things that can all be fixed.
And to answer your last question, because our satellites are spec'd to provide the same EIRP on the ground, the ground terminals used are the same as those in use today for GEO telecoms. These terminals are all off-the-shelf and very low-cost compared to the terminals necessary for a LEO-based network.
You're putting the Tx power into the equivalent of just one or two 36 MHz Ku transponders per satellite? Fewer transponders per satellite in a tradeoff for greater Tx power in a smaller bus?
1. What bandwidth capacity are you aiming for per spacecraft?
2. Are you using commercial or rad hard parts?
3. Is there a deployable antenna that makes the spacecraft larger than 3'x3'x3'?
2. For various reasons it doesn't make sense to go into that level of detail on a public forum.
3. Yes.
I'm interested in what the total system gain, EIRP and power looks like in an Astranis spot beam from geostationary, as compared to a current-generation 4000 to 6500 kilogram geostationary satellite with Ku and Ka band spot beams.
I am optimistic but also skeptical. The size and power of the satellite will influence what the size of VSAT terminals needs to be, and also the earth stations/major teleports. The example size of the satellite shown in the URL is so much smaller than current geostationary satellites that I don't see how the Tx power from each transponder will be anywhere near the power on a much bigger, costlier satellite.
Let's say for example I have put together from industry standard components, a 3.0 meter compact cassegrain Ku-band antenna in a remote part of Nepal, with a 40W BUC and a relatively recent Comtech EF Data modem. Are you planning on selling 1:1 dedicated capacity SCPC (and MCPC) type transponder kHz on a monthly basis? Or are you planning on standardizing on your own type of VSAT hardware terminal in bulk and selling contended access only?
Where do you see your value proposition for high capacity IP trunk links as compared to an ISP buying a 2 x 1.8m dish o3b terminal, and dedicated capacity through o3b? What will your $/Mbps rate look like compared to o3b with a monthly spend of 2500 or 3500 dollars?
I am kind of concerned that your answers to others' questions in this thread are vague and noncommittal.
One more question. Do you intend to:
(A) lease raw transponder kHz capacity to third party end users and ISPs (eg: the ku spot beams I can get on Russian satellites covering Afghanistan and a check for $4500 USD a month,
or (b) is your business plan to operate both the satellites and the earth stations, and resell fully packaged VSAT services directly to end users?
See also: Theranos, uBeam, etc.
Hardware startups are costly and hard.
Now do it on super hard mode and build a thing that has to go 36,000+ km away, never to be seen or touched by a human, and make it super reliable.
I'm always happy to answer basic questions about what we're doing. But questions around very specific technical details, especially when it comes to things that give us a competitive advantage like our antenna design, just aren't appropriate for a public forum. Thanks for understanding.
For more detailed questions we may or may not be able to answer them via email. But certainly I'd be happy to take a look at it and if its appropriate put them in touch with the relevant member of the team. (See-- https://www.astranis.com/about/)
The amount of Mbps I could push through that will be greater than if I do the same setup with a pair of 1.8m dishes. You can't know your Mbps figure for a dedicated geostationary satcom link until you know you RF link budget, system gain, and how close you can get to the Shannon limit. The same amount of kHz (same dollar spend per month) could be used at 16QAM 5/6 or at QPSK 1/2 modulations, with very different Mbps figures.
It's off course very welcome if they can get higher transfer speeds, cleaner and lighter satellites and newer technologies to the mix, but that's it. The biggest problem with satellite internet: the latency, is not going to be solved.
Which is fine, I must say, since they are in the business of bringing Internet to where there's none. But these new Internet users will arrive without access to the Internet's most incredible features, such as real time voice and video communication, interactive website experiences and online gamming.
* google/$INFORMATION
* Wikipedia
* podcasts
* spotify/torrent/$MUSIC
* blogs/twitter
* youtube/netflix/torrent/$VIDEO
pretty much in that order. None of which would be a problem on satellite (albeit less convenient) but would make a day/night difference for me.
As for the "interactive website experiences", that's usually the part I like the least about a website, which is why I use uMatrix most of the time, making pages more readable (or, depending on the JS affinity of the people making them, completely unreadable)
To get to the lower costs that we're aiming for, going to software defined radios was a necessary step. That's because it gives us the ability to build many satellites that are as identical as possible without hardwiring in the specific frequencies like they do with analog satellites today. It's hard to overstate the importance of that technology for what we're doing and the low cost targets we need to hit to get unconnected people online.
All interactive traffic is latency sensitive (have built middleboxes to improve latency issues with tcp and other protocols)
On the other hand it is completely possible that SpaceX's ground stations will use HW that is similar to their CPE box and thus they can build ridiculous amount of such ground stations (ie. at every IXP or so, althought the "lightweith non-IP transport" proclamation somehow precludes doing that)
[1] https://motherboard.vice.com/en_us/article/d34bmk/iridium-ne...
I know this is a YC forum but seeing the Astranis team's responses to people asking very incisive questions is troubling. Maybe they're far better at engineering than building confidence but I detect that sort of single minded dismissal (often of objective reality) that plagues a lot of entrepreneurs.
Maybe this is unfair but it sounds like someone got latched onto the idea of "micro-satellites" and won't let it go, ending up with "we can conceivably put up only X, so they'd have to be geosynchronous". Maybe there's a reason SpaceX is doing a LEO constellation, regardless of their unfair advantages in that regard.
Of course latency is an issue. Engineers will run away. Maybe you don't need them to succeed, maybe they are 0.1% of the market. Of course, where would Apple be without software engineer and designer buy in? Maybe the average customer shouldn't care, 'cause they're all high latency ok. Doesn't stop them from being swayed by marketing. A single infographic showing why low latency is better -- all else being equal -- what are customers going to choose?
Not sure why YC would have invested in this other than to broaden their portfolio. The chances of this company becoming a unicorn must be vanishingly small. If unicorns are no longer the VC mantra, cool, I've got a lifestyle business you can throw money at, provided there are zero expectations.
By all means prove me wrong and best of luck to you. Take this is as constructive criticism. If you're going to engage anyone in public bring your A game.
- The speed of light is ~50% higher in vacuum than in fiber[1]
- Fiber on the ground doesn't follow straight lines
[1] https://www.quora.com/What-is-precisely-the-speed-of-light-i...
Are your terminals going to include TCP Performance Enhancing Proxies (PEPs)? The TCP three way handshake followed by the TLS handshake makes it kind of painful to browse on an unaccelerated network with a GEO hop. And this is before you get to the latency from the ground station to the website. The problem gets even worse in Web2.0 world where everything is running off of tiny queries that the web app developers assume will be back in 50ms or so.
TCP PEPs can only do so much too (cutting down on the roundtrips and ramping up the window size more quickly), eventually you hit the hard limits of physics.
TLS setups however as you note are a whole new ball of wax, especially if the link has a bit of loss to go along with the latency.
I have worked over ssh over internet connections with satellite-class latency and I can say it is painful. (Emacs shell mode can help)
You probably think that 'the web' is a high latency application. It probably should be, and maybe it was in 2000. Since then, web developers have gotten into the habit of using AJAX indiscriminately, plus they feel pressured to add features such as customized fonts, advertising, third party tracking, etc. I am not sure if CDN is really a net positive when a web site might need to do 30 DNS lookups because it uses 30 CDNs. It just takes one of those lookups to be slow to obliterate the savings from the CDN. CDNs might help with the median, even the average load time, but I am not sure they help the 95% load time which is what causes customer pain.
Add up all those round trips and the overhead of access control (maybe those patents on slotted ALOHA for satellite applications have expired by now) and you are talking upwards of 0.5 sec and it doesn't take many round trips for that 0.5 sec to turn into 5 to 10 seconds.
Worst thing is that people who are developing locally or from places with fast connections to the data center will think these apps are really fast.
Stationary orbit is at a distance of 35800 km above sea level, which implies a one way latency of 110 ms based off the speed of light. Since any request from a user requires a total of 2 round way trips (one for request, one for response), the minimum latency for a request is 440 ms.
Avg latency with fiber is something like 30-60 ms, so we can assume an average request with Astranis will have ~500 latency.
Most modern webpages will not be able to support such latency. Astranis will need to essentially cache webpages on demand and deliver them to the end user as a fully rendered page, which will introduce security headaches.
I don't see why Astranis chose this vs a lower orbit.
Please elaborate? This makes no sense to me. Certainly, this is not the case for terrestrial communication (request/response latency is only 2× the one-way latency).