Starlink : Hardware Design / Manufacturing

[M.E.T.]

Tim Farrar is saying on twitter that current Starlink satellite and terminal wouldn't support crosslink, any reason to believe his claims?

https://twitter.com/TMFAssociates/status/1301529567308337152

It seems that he's saying Starlink is the same as OneWeb, basically just acting as a repeater between terminal and gateway, but I thought the general consensus is that that's not the case?

(I know this guy is super shady, just curious if he has any basis to make this claim, since I'm not familiar with the technology details such as TDD)

This guy is probably the number one Starlink FUD monger on the web. A lot of his definitive declarations on Starlink’s imminent doom have been proven baseless one by one. He has not acknowledged any of these achievements.

He is (emotionally at least) heavily invested in Starlink’s failure. So take his comments with a pinch of salt.

[woods170]

This guy is probably the number one Starlink FUD monger on the web. A lot of his definitive declarations on Starlink’s imminent doom have been proven baseless one by one. He has not acknowledged any of these achievements.

He is (emotionally at least) heavily invested in Starlink’s failure. So take his comments with a pinch of salt.

Emphasis mine.

Not "probably". He IS the number one Starlink FUD monger. Even when people call him out for him being verifiably wrong he will still maintain that he is right, or he will move the goalposts. As happened in the tweets called out earlier in this thread.

There is two reasons IMO why he is specifically targeting Starlink:

1. SpaceX never bothered to consult with him while Tim considers himself to be THE guy to be consulted (you should see his online resume)
2. Teledesic was one of Tim's very first "love-childs". But Teledesic failed miserably after getting only one demo satellite into orbit. And now it looks like Starlink is going to succeed where Teledesic (and by extension Tim) failed. He doesn't like that one d*mn bit IMO.


Hence IMO his negative attitude towards Starlink.

[geza]

First orbital test of optical com between Starlink sats.
https://www.teslarati.com/spacex-starlink-space-lasers-first-orbital-test/

[RedLineTrain]

Not "probably". He IS the number one Starlink FUD monger. Even when people call him out for him being verifiably wrong he will still maintain that he is right, or he will move the goalposts. As happened in the tweets called out earlier in this thread.

I do find it interesting to watch the falsification progression, so I peek in from time to time.  His negative pronouncements might be a marker showing what the larger players in the industry are thinking at the moment, Amazon and Iridium excepted.

But folks of this type do not give a glimpse of reality.  The world they know is as integrators and operators.  I don't think they understand an entity that does everything from designing its own silicon to launching the constellation reusably to answering support calls from consumers.

[JamesH65]

Why would the consumer terminal care? Signal goes up to a satellite, signal comes down from the satellite.
Currently the signal from a terminal goes from terminal->sat->ground->backbone->ground->sat->terminal

The crosslinks would enable terminal->sat*N->ground->backbone->ground->sat*N->terminal or even a dedicated terminal->sat*N->terminal transmission.
Note that there's no change to the terminal->sat or sat->terminal interface.

The crux of the argument seems to be the satellites cannot host enough compute to handle the routing themselves and Musk is a con-man.

Smells very similar to the end-stage flailing of Twitter Tesla shorts around mid-2019. Dubious/vague technical claim plus character attack, and repeat.

Quite. Nothing to do with the ground terminals at all. It's a bit like saying your router at home stops working if your internet provider changes their backbone. Which it doesn't.

This guy is talking nonsense.

[soltasto]

He also believed (and probably still does) that the motors of the Starlink User Terminal are used for normal operation and not only for setup. I (an electronics engineer) explained to him that an antenna that is both mechanically steered and electronically steered for normal use is stupid and doesn't make any sense and his answer was that it's like that because "That’s what happens with an iterative system level design, you have to constantly adjust other components when another part of the system can’t deliver to spec. So you add motors to the user terminal as the simplest tweak to address the satellite’s shortcomings" which makes no sense what so ever. At that point I knew it didn't make any sense to continue arguing as basically he is advocating that everyone at Starlink is an idiot.

[abaddon]

I actually find the idea that routing could be ground terminal based interesting.  It would increase the cost of the ground terminals, but CPU on Earth is much cheaper than on orbit.  That could be attractive.  However, it would be complicated to have ground terminals have an up-to-date picture of current traffic utilization of the constellation to efficiently use and avoid congestion, it's much easier to get that on the satellites themselves.  And aside from that complexity, routing through Starlink ought to be dead simple, as a fully SpaceX built and relatively homogeneous network.  At which point, if it is so simple, it doesn't do much to do it on the ground terminals in the first place...

Yeah, this in no way passes the smell test.

[vsatman]

This guy is talking nonsense.

I am not familiar with Tim, but I can say that the transmission from the user terminal to the satellite goes normally on the one frequency, if you have a cross link, then you need to somehow divide the information streams one goes  to the ground gateway and the other to another satellite through the cross link , this can be done either by having  data processing on board or by having 2 separate frequences (2 signals)  at  at the user terminal, that is, you must have a terminal of a different design
 one for simple access to internet via gateway and second with two transmitters  and two receivers for  using cross link

[gongora]

I've been wondering how the inter-satellite links would work.  With optical links, don't the send and receive elements both need to be actively pointed at each other?  If so then a satellite sending information can't randomly pick another satellite on some instantaneously calculated optimal path to send the data to, because that other satellite wouldn't know to receive the information.  Wouldn't the data need to go over predefined routes within the constellation?  With a large number of satellites there could be a large number of defined routes, but near the end points there may need to be some sub-optimal routing for a small number of hops.  For really high value routes (New York to London or various other combinations of commercial centers) they could define routes to always keep those as low latency as possible.

[oldAtlas_Eguy]

First orbital test of optical com between Starlink sats.
https://www.teslarati.com/spacex-starlink-space-lasers-first-orbital-test/

This is significant.

Just need SpaceX direct confirmation.

Also it was expected because of the SpaceX advertisement of job  for Laser comm manufacturing engineer to improve the management of the production of these devices. It just means that instead of large scale deployments (all sats on a launch) is much sooner than thought. Originally it was thought to occur Q1 2021 but now seems possible for Q4 2020.

[Nomadd]

I've been wondering how the inter-satellite links would work.  With optical links, don't the send and receive elements both need to be actively pointed at each other?  If so then a satellite sending information can't randomly pick another satellite on some instantaneously calculated optimal path to send the data to, because that other satellite wouldn't know to receive the information.  Wouldn't the data need to go over predefined routes within the constellation?  With a large number of satellites there could be a large number of defined routes, but near the end points there may need to be some sub-optimal routing for a small number of hops.  For really high value routes (New York to London or various other combinations of commercial centers) they could define routes to always keep those as low latency as possible.

I always thought that configuring that mess would be way harder than building the hardware. Long term links with the two neighbors in your orbit and to others in the next plane over with the same altitude and inclination might be simple, but trying to figure routing and setting up links between sats in different altitudes and inclinations just hurts my brain.

[gongora]

First orbital test of optical com between Starlink sats.
https://www.teslarati.com/spacex-starlink-space-lasers-first-orbital-test/

This is significant.

Just need SpaceX direct confirmation.

SpaceX said during the last Starlink launch webcast that they had tested a link between two sats.  That's why Eric wrote the article.

[DistantTemple]

I've been wondering how the inter-satellite links would work.  With optical links, don't the send and receive elements both need to be actively pointed at each other?  If so then a satellite sending information can't randomly pick another satellite on some instantaneously calculated optimal path to send the data to, because that other satellite wouldn't know to receive the information.  Wouldn't the data need to go over predefined routes within the constellation?  With a large number of satellites there could be a large number of defined routes, but near the end points there may need to be some sub-optimal routing for a small number of hops.  For really high value routes (New York to London or various other combinations of commercial centers) they could define routes to always keep those as low latency as possible.

I'm guessing here...
Unperturbed orbits are very reliable, and every satellite could have the database for the current Starlink fleet, and a routine for keeping up to the microsecond positioning of all near neighbours. Reasonable pointing from that is just maths. Maybe there is a homing routine to centre the beam once acquired.
An alternative, or addition is for sats to communicate with neighbours via ground stations, transmitting their current and predicted position, and agreeing to establish "lightspeak".
Further, using laser links forward and behind in one orbit would be much easier. This could be how the initial experiments are being done, and tracking adjacent orbits being harder might be later. Finally communicating from a NE(ish) travelling sat, to one on its "downward" SE(ish) section of orbit, will be most difficult as the angle will change very quickly. Will that be attempted? I assume this can be put off as the first two should give a great improvement, (without wearing out the dish direction motors!)

Edit: Nomad got there first.... less unnecessary words make a quicker posting!

[Mandella]

This guy is talking nonsense.

I am not familiar with Tim, but I can say that the transmission from the user terminal to the satellite goes normally on the one frequency, if you have a cross link, then you need to somehow divide the information streams one goes  to the ground gateway and the other to another satellite through the cross link , this can be done either by having  data processing on board or by having 2 separate frequences (2 signals)  at  at the user terminal, that is, you must have a terminal of a different design
 one for simple access to internet via gateway and second with two transmitters  and two receivers for  using cross link

So Tim is guessing that SpaceX would have to use the second choice (two frequency user terminal) since he can't believe that Starlink could have the processing ability on board.

All right. That's not necessarily true, but even if it were why can't the user terminals being shipped initially have that capability already designed in and waiting for the crosslinks?

[russianhalo117]

I've been wondering how the inter-satellite links would work.  With optical links, don't the send and receive elements both need to be actively pointed at each other?  If so then a satellite sending information can't randomly pick another satellite on some instantaneously calculated optimal path to send the data to, because that other satellite wouldn't know to receive the information.  Wouldn't the data need to go over predefined routes within the constellation?  With a large number of satellites there could be a large number of defined routes, but near the end points there may need to be some sub-optimal routing for a small number of hops.  For really high value routes (New York to London or various other combinations of commercial centers) they could define routes to always keep those as low latency as possible.

In my understanding I'm going to make use of a general comparison to geo survey mapping with modern automated instruments
To install permanent GPS receivers and other instruments in the Pacific Northwest's quadrangles they align mapping instruments laser beams based on a computer generated triangulation map so they get the best points for installation. These are used to study the clockwise rotation of the North American Plate below British Columbia occurring in the region that causes routine silent quakes that tensions the crusts lock zone further every 14 months.

In space this is easier as the spacecraft can have the inter satellite links permanently installed at the intended points around the spacecraft as the center of the spacecraft is the node of the surrounding right triangles. Each optical link would have say 7 DOF to adjust to real time conditions compared to the onboard map. The position info would be continuously updated aboard each sat. The alternative path is the follow on to eLISA which expands the number of sats beyond three sats any they use fixed mounting with micro steering of the optical lenses to get alignment. With radio waves you steer the Digital beams on the patch panel attennae. These are used to relay position and other data to each sat.

[oldAtlas_Eguy]

First orbital test of optical com between Starlink sats.
https://www.teslarati.com/spacex-starlink-space-lasers-first-orbital-test/

This is significant.

Just need SpaceX direct confirmation.

SpaceX said during the last Starlink launch webcast that they had tested a link between two sats.  That's why Eric wrote the article.

Thanks, missed that piece of evidence.

[DistantTemple]

Will SX develop a new in-house routing layer? SRP, Starlink Routing Protocol? Existing networks do not have their nodes constantly moving, reshaping the routes via changing routers.
Also Since SX (we assume) plans to sell services to stock exchanges, international finance, the military, and "secret service", some way of hiding the routing from any kind of snooping....
I know too little about even TCP/IP to go on..... Just everyone else has to fit into the existing internet..... backbone, but SpaceX is effectively making a new network. At first it will rely heavily on the existing... but once the ISL are up, Many connections will be entirely within SL. And even those that only start or end within SL (subscribers/clients) may spend the majority of their journeys within SL, and only need (translation) to the local internet for the last few 10's of miles.

[envy887]

This guy is talking nonsense.

I am not familiar with Tim, but I can say that the transmission from the user terminal to the satellite goes normally on the one frequency, if you have a cross link, then you need to somehow divide the information streams one goes  to the ground gateway and the other to another satellite through the cross link , this can be done either by having  data processing on board or by having 2 separate frequences (2 signals)  at  at the user terminal, that is, you must have a terminal of a different design
 one for simple access to internet via gateway and second with two transmitters  and two receivers for  using cross link

According to the 2017 SpaceX filing, the user terminals receive on one frequency and transmit on another, at least for V band. Shouldn't they be able to do full duplex? Either with 2 antennas, or even using alternating elements in the phased array for Tx/Rx.

Also, why would you need different frequencies to use the ISLs? If the routing is done on the satellite, then the user terminal doesn't care about anything behind the router. It's just sending data to the sat, and getting data back.

If routing is done at the ground station, that is, the sats are just bent pipe(s), then there should only ever be one path from user terminal to ground station at a time. The user terminal shouldn't care how many ISL bounces there are before the single comes out the other end of the pipe at the ground station. It just sends data into the pipe, and data comes back out. Unless, (and this appears to be Tim's argument), the time-division duplexing gets messed up by the additional latency of the ISL hops. But that still shouldn't matter if they can either do full duplex, or reconfigure TDD timeslots on the fly.

In short: TDD over ISL should not be a problem that can only be surmounted by a new terminal and sat.

[russianhalo117]

Will SX develop a new in-house routing layer? SRP, Starlink Routing Protocol? Existing networks do not have their nodes constantly moving, reshaping the routes via changing routers.
Also Since SX (we assume) plans to sell services to stock exchanges, international finance, the military, and "secret service", some way of hiding the routing from any kind of snooping....
I know too little about even TCP/IP to go on..... Just everyone else has to fit into the existing internet..... backbone, but SpaceX is effectively making a new network. At first it will rely heavily on the existing... but once the ISL are up, Many connections will be entirely within SL. And even those that only start or end within SL (subscribers/clients) may spend the majority of their journeys within SL, and only need (translation) to the local internet for the last few 10's of miles.

TCP is out dated and used by HTTP/1.1 and HTTP/2 (slated for depreciation). HTTP/3 uses QUIC (Quick UDP Internet Connections) and is the successor to TCP.
Source: https://quicwg.org/base-drafts/draft-ietf-quic-http.html

[oldAtlas_Eguy]

I've been wondering how the inter-satellite links would work.  With optical links, don't the send and receive elements both need to be actively pointed at each other?  If so then a satellite sending information can't randomly pick another satellite on some instantaneously calculated optimal path to send the data to, because that other satellite wouldn't know to receive the information.  Wouldn't the data need to go over predefined routes within the constellation?  With a large number of satellites there could be a large number of defined routes, but near the end points there may need to be some sub-optimal routing for a small number of hops.  For really high value routes (New York to London or various other combinations of commercial centers) they could define routes to always keep those as low latency as possible.

In my understanding I'm going to make use of a general comparison to geo survey mapping with modern automated instruments
To install permanent GPS receivers and other instruments in the Pacific Northwest's quadrangles they align mapping instruments laser beams based on a computer generated triangulation map so they get the best points for installation. These are used to study the clockwise rotation of the North American Plate below British Columbia occurring in the region that causes routine silent quakes that tensions the crusts lock zone further every 14 months.

In space this is easier as the spacecraft can have the inter satellite links permanently installed at the intended points around the spacecraft as the center of the spacecraft is the node of the surrounding right triangles. Each optical link would have say 7 DOF to adjust to real time conditions compared to the onboard map. The position info would be continuously updated aboard each sat. The alternative path is the follow on to eLISA which expands the number of sats beyond three sats any they use fixed mounting with micro steering of the optical lenses to get alignment. With radio waves you steer the Digital beams on the patch panel attennae. These are used to relay position and other data to each sat.

As far as routing on a disjointed wireless network with endpoints transitioning between infrastructure with significantly different routing. This has already been solved by the Cell Phone industry. The Starlink case is just a little more extreme but would use same methodologies. Think of Starlink as a very distributed 5G network. Which literally it is. Except it does not use the Cell frequencies.

To link up Laser comms initially and maintain the positional data of Starlink sat  neighbors in relationship to the sat's own position and orientation is maintained by uplinking this data from the ground. Once linked in then a simple optical tracking mechanism  is used to maintain pointing accuracy on the prefered object that is also pointing back at the sat with it's own Laser. The problem comes when one leg of the by directional Laser comm fails and there is no longer any incoming Laser to track to refine optical tracking. This would cause the Laser subsystem to forever be in acquisition mode until it is disabled entirely.

Added: Think of this case. You are streaming a show on your Cell Phone while sitting at home over your wireless network but then your power goes out. If you have that one little setting on your phone that says use Cell data to backup weak WiFi your show streaming may not even falter or go into buffering mode even though the routing is completely different across a completely different ISP. The highly dynamic rapid changing routing between endpoints has been solved and is in operation currently. Even between to wire endpoints the route is changing due to traffic congestion along the current route causing another route that has higher delay to be chosen but with fewer packet drops since that other route has less traffic congestion. This is happening seamlessly and without much visibility of it's occurrence to the users at the endpoints.