Author Topic: Starship On-orbit refueling - Options and Discussion  (Read 742638 times)

Offline OTV Booster

  • Senior Member
  • *****
  • Posts: 5429
  • Terra is my nation; currently Kansas
  • Liked: 3750
  • Likes Given: 6479
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2140 on: 02/28/2023 08:32 pm »
While writing the two posts above it struck me that if the depot and other ship are physically tightly bound the control systems had also better be tightly bound.


Would it be best if the Depot completely took over and controlled both ships? Every cooperative arrangement that I come up with for settling thrust and attitude control seems to get more complicated the deeper I get into it. The last thing we want is the two ships fighting each other because of minor calibration issues.
It seems like it would be a relatively straightforward thing to use the IMU's and star trackers from one ship to feed the control computers in both. AFAIK, they use Ethernet protocol networking to communicate within the vehicle, getting one of the flight computers to poll the network on the other ship shouldn't be that difficult. They generally seem to prefer to keep the control computers as close as physically possible to the thing they'll be controlling (for example, the engine controller is mounted directly to the side of each engine), so I think it's unlikely they would want to send commands across the ship-ship link. For simplicity they could also just have one ship be operating dumb, just providing a fixed amount of ullage thrust while the other handles orientation.
Yeah, it's not the actual implementation (RCS or thrust) that needs coordination, it's the decision on what needs to be done. The other ship would best do what it's told while the depot, designed for just this, makes the decisions.


The depot star tracker would be the one in active use and the absolute global coordinate system would be immaterial for the other ship. Once it's under depot control it would get commands like 'rotate Z axis -3deg'.
We are on the cusp of revolutionary access to space. One hallmark of a revolution is that there is a disjuncture through which projections do not work. The thread must be picked up anew and the tapestry of history woven with a fresh pattern.

Offline OTV Booster

  • Senior Member
  • *****
  • Posts: 5429
  • Terra is my nation; currently Kansas
  • Liked: 3750
  • Likes Given: 6479
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2141 on: 02/28/2023 08:40 pm »
A SpaceX example of the Master/Slaving of the Guidance computer sets is the F9/D2 stack. The Dragon is the master of everything until separation. Once a stage separates away it is then its own master.

The SS and SH will likely operate similar to F9 in the implementation of the software. The question would be which of the two vehicles Tanker/Depot would have all the added software loaded to run as a super master of a pair of SS with the other having software to be SS slave. The SS operating as a slave would not be a normal as it is currently software set on a SS. That software would probably look very similar to the software on the SH to enable it to be a slave to the SS.

SpaceX has successfully done it before on F9 so doing it for the Depot/Tanker case should not prove that difficult. Especially once they prove out the software for the Master/Slave full stack Starship launch software packages.
ISTM that depot should be the master. Presumably it's the one with mission specific hardware. Why do differently for the mission specific software? The mission in this case is propellant transfer.
We are on the cusp of revolutionary access to space. One hallmark of a revolution is that there is a disjuncture through which projections do not work. The thread must be picked up anew and the tapestry of history woven with a fresh pattern.

Offline TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4911
  • Tampa, FL
  • Liked: 3649
  • Likes Given: 684
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2142 on: 02/28/2023 09:15 pm »
A SpaceX example of the Master/Slaving of the Guidance computer sets is the F9/D2 stack. The Dragon is the master of everything until separation. Once a stage separates away it is then its own master.

The SS and SH will likely operate similar to F9 in the implementation of the software. The question would be which of the two vehicles Tanker/Depot would have all the added software loaded to run as a super master of a pair of SS with the other having software to be SS slave. The SS operating as a slave would not be a normal as it is currently software set on a SS. That software would probably look very similar to the software on the SH to enable it to be a slave to the SS.

SpaceX has successfully done it before on F9 so doing it for the Depot/Tanker case should not prove that difficult. Especially once they prove out the software for the Master/Slave full stack Starship launch software packages.

Note that this is a pretty straightforward piece of software engineering.  Master/slave negotiations are used for all kinds of distributed computing.  Typically, they're just states in the finite state machine that runs your system.  After the negotiation, one side is the master and does most of the computation, while the other side is the slave and simply receives commands (events) from the master to do stuff.  How you divide up the command protocol is more art than science, and often depends on the organization of your GN&C software.

BTW:  Is the D2 in charge of most of the ascent process?  Normally, the F9 S2 has the main computing system, and is responsible for guidance and nav, but it likely relies on the core stage for control during ascent.  Following staging, it then has full control of GN&C for itself and the payload, while the core then owns all of its own GN&C through landing.

D2 can obviously decide to send an abort event to the S2, but I'd think that even then, the S2 was responsible for engine shutdown and a handshake back to the D2 indicating that it was good to do separation and escape.

Offline OTV Booster

  • Senior Member
  • *****
  • Posts: 5429
  • Terra is my nation; currently Kansas
  • Liked: 3750
  • Likes Given: 6479
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2143 on: 02/28/2023 09:18 pm »
While writing the two posts above it struck me that if the depot and other ship are physically tightly bound the control systems had also better be tightly bound.

Would it be best if the Depot completely took over and controlled both ships? Every cooperative arrangement that I come up with for settling thrust and attitude control seems to get more complicated the deeper I get into it. The last thing we want is the two ships fighting each other because of minor calibration issues.

It will certainly be true that the coupled pair of ships (tanker/depot, depot/target, or even tanker/target) will form a single controlled system.  Whether one ship acts as the master or they operate cooperatively is too far in the weeds even for me.

However, this has a direct impact on the physical coupling of the pair.  I doubt that it's advisable to have the pair tandem free-flying and get this to work--the control loop is just too diffuse, and even the kinematics of the pair will get weird.  Even a loosely coupled but flexible berthing will induce unpredictable oscillations that may be hard to damp out.

This is why I expect the berthing to be capable of handling decent-sized loads between the two ships with minimal flex and oscillation.



Just to review the bidding on things we've talked about for attitude control, prox ops, and ullage acceleration.  From smallest torques/translations to largest:

1) CMGs (I think you guys have convinced me that this might be useful).
2) Cold gas RCS, fed from ullage pressure only.
3) Cold gas RCS, fed from supercritical COPVs.
4) Combusting gas RCS/thrusters, fed from supercritical COPVs.

I'm pretty sure you need #4 no matter what, if for no other reason than ullage acceleration needs more impulse than can be readily generated without the enthalpy of combustion, and SpaceX likely has to develop them for lunar landing and takeoff ops.  Then the question becomes what combination of #1-#3 is needed for fine attitude control, both coupled (during refueling) and uncoupled (during attitude maintenance to minimize boil-off).

Just remember that the minimum impulse bit for any thrusters can be relatively large for Starship, because the total mass and moments of inertia are so large.
I'm pretty much in agreement but think about decision by committee. Committees are good at finding the questions to ask (and a lot of irrelevant questions) and defining responses that are unacceptable, but making decisions? LoL. Everything would boil off before the two ships reach consensus.


CMG's vs thrusters. This looks like a good idea but there are so many trades it really needs to be treated as an option pending operational experience. Thrusters absolutely for translation and hot gas for ISP. HP vs LP cold gas? That gets us back to the trades. We can noodle some of this but on orbit experience will inform on what's really needed vs a hypothetical capability.


An empty depot will have a lot of mass at one end and near nothing at the other. A small vent or burn at the bottom would be a slap up side the head at the top. One trade to look at is translation while empty. Low thrust hot gas at the bottom and hypothetically, CMG's keeping the top aligned so it stays translation and not rotation. Then there is every state up to and including completely full. It can all be modeled but we don't know exactly what will be the most useful without experience. It's good to be able to do everything at high efficiency (by some arbitrary definition) but in this real world maybe the low use behaviors don't need all that much optimization if it's at he expense of the high use maneuvers.


Let's go get some experience, Yeah!
We are on the cusp of revolutionary access to space. One hallmark of a revolution is that there is a disjuncture through which projections do not work. The thread must be picked up anew and the tapestry of history woven with a fresh pattern.

Offline TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4911
  • Tampa, FL
  • Liked: 3649
  • Likes Given: 684
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2144 on: 02/28/2023 09:31 pm »
ISTM that depot should be the master. Presumably it's the one with mission specific hardware. Why do differently for the mission specific software? The mission in this case is propellant transfer.

Shouldn't make a bit of difference.  It's a computer network.  Which bits get twiddled by which CPU is an almost arbitrary choice.  If I were doing it, I'd let both CPUs be either master or slave.  No doubt you make one the preferred choice, but either one should be able to take over in the event of a failure.

The more interesting choices are how you separate the CPUs from the various I/O systems.  Do you let a master on one vehicle reach across and tweak I/O (i.e., directly command thrusters or CMGs) on the other vehicle, or do you relay commands through the slaved CPU?  Keeping everybody in sync, so any element can take over in the event of a failure, is hard.

I'm pretty much in agreement but think about decision by committee. Committees are good at finding the questions to ask (and a lot of irrelevant questions) and defining responses that are unacceptable, but making decisions? LoL. Everything would boil off before the two ships reach consensus.

It's not a committee.  It's a set of coupled FSMs that are carefully coordinated by defining a protocol containing the events needed to keep the system behaving properly.  Yes, master/slave is often a very simple (and very effective) basis for writing your state machines and defining the events.  But think about this more like cloud computing than two people arguing over the best course of action.

Offline oldAtlas_Eguy

  • Senior Member
  • *****
  • Posts: 5317
  • Florida
  • Liked: 5022
  • Likes Given: 1584
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2145 on: 02/28/2023 10:54 pm »
ISTM that depot should be the master. Presumably it's the one with mission specific hardware. Why do differently for the mission specific software? The mission in this case is propellant transfer.

Shouldn't make a bit of difference.  It's a computer network.  Which bits get twiddled by which CPU is an almost arbitrary choice.  If I were doing it, I'd let both CPUs be either master or slave.  No doubt you make one the preferred choice, but either one should be able to take over in the event of a failure.

The more interesting choices are how you separate the CPUs from the various I/O systems.  Do you let a master on one vehicle reach across and tweak I/O (i.e., directly command thrusters or CMGs) on the other vehicle, or do you relay commands through the slaved CPU?  Keeping everybody in sync, so any element can take over in the event of a failure, is hard.

I'm pretty much in agreement but think about decision by committee. Committees are good at finding the questions to ask (and a lot of irrelevant questions) and defining responses that are unacceptable, but making decisions? LoL. Everything would boil off before the two ships reach consensus.

It's not a committee.  It's a set of coupled FSMs that are carefully coordinated by defining a protocol containing the events needed to keep the system behaving properly.  Yes, master/slave is often a very simple (and very effective) basis for writing your state machines and defining the events.  But think about this more like cloud computing than two people arguing over the best course of action.
In the software guidance systems it is more of a hierarchical assignment of takings. At the top is mission -> navigation -> attitude control -> engine controls/aerodynamic surfaces control. In the case of a F9/D2 the D2 is doing the first two and sometimes maybe a little of the third as well. The stages are each under command executing the next 2 tasking levels. Note is that some information like IMU data traverses up through all the layers since even some of the actions at the lowest layers need that data without delay.

In the pair of SS case it is correct to think that either computer set could do the work of the first 2 levels but only the local computers can do the last 2 levels since the control loops need to be tight and reliable. It is that which keeps the general initial stability of the pair. The higher levels must deal with control loop interference patters by 2 vehicles doing active stabilization. Fortunately it may be possible to cheat some here in that the torques involved are mostly small and slow to build to being problems. Allowing the higher level to then dampen them out.

Active control systems are a headache.

Offline TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4911
  • Tampa, FL
  • Liked: 3649
  • Likes Given: 684
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2146 on: 03/01/2023 03:01 am »
In the pair of SS case it is correct to think that either computer set could do the work of the first 2 levels but only the local computers can do the last 2 levels since the control loops need to be tight and reliable. It is that which keeps the general initial stability of the pair. The higher levels must deal with control loop interference patters by 2 vehicles doing active stabilization. Fortunately it may be possible to cheat some here in that the torques involved are mostly small and slow to build to being problems. Allowing the higher level to then dampen them out.

Active control systems are a headache.

One thing to remember is that highly precise attitude control of the coupled system after berthing/docking isn't nearly as important as highly precise attitude control of the uncoupled system during prox ops.  But the uncoupled system, rather than having some kind of master/slave relationship, has an active/passive relationship to simplify it.  One vehicle just needs to null out its rotational rates wrt the orbital frame of reference, and the other one does all the active translation and rotation to make everything line up.

Once they're linked, you can use a pretty forgiving control loop to maintain a safe attitude.  But the amount of boil-off during the coupled period is small enough that you don't need to hold the precise attitude that the depot would need to minimize direct insolation.

Still a headache, but a manageable one.

Offline Twark_Main

  • Senior Member
  • *****
  • Posts: 4117
  • Technically we ALL live in space
  • Liked: 2207
  • Likes Given: 1332
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2147 on: 03/02/2023 06:07 pm »
A SpaceX example of the Master/Slaving of the Guidance computer sets is the F9/D2 stack.


I would say a closer analogy would be FH side boosters and core. These are both complete stages with (largely) identical avionics, flying in formation in a side-by-side configuration. They experience much greater loads than refilling, but they also have stronger connections, but both are 'no stronger than necessary.'

The Dragon is the master of everything until separation. Once a stage separates away it is then its own master.

Do we have a source for this?

I would have thought the second stage avionics would perform ascent GNC, for commonality with non-Dragon F9 flights.

Offline Greg Hullender

  • Full Member
  • ****
  • Posts: 699
  • Seattle
    • Rocket Stack Rank
  • Liked: 516
  • Likes Given: 376
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2148 on: 03/16/2023 05:00 pm »
. . . think about decision by committee. Committees are good at finding the questions to ask (and a lot of irrelevant questions) and defining responses that are unacceptable, but making decisions? LoL. Everything would boil off before the two ships reach consensus.
When you use "committees" of computers, it's called distributed computing. There has been a great deal of work done to resolve the problem of making such a system reach consensus. In the most general case, this is a fiendishly difficult problem. Algorithms like Paxos are used to solve it, and they are not easy to wrap your head around.

They also tend to be relatively slow, so you normally only use these to let a set of contending processors elect a leader. For example, when I was at Microsoft on the project now called Bing, we had to coordinate thousands of servers which individually had half-lives of a year or so. To oversimplify a bit, we used Paxos to let them elect a leader, and, if the leader failed, to replace it. For all the problems we had with Bing over the years, Paxos never failed us. Individual servers failed, but the ensemble was immortal.

With one or more Starships trying to do formation flying, it doesn't seem like there would be all that many processors involved, so something like Paxos would probably be overkill, but it proves there is at least a solution that is known to work.

Offline TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4911
  • Tampa, FL
  • Liked: 3649
  • Likes Given: 684
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2149 on: 03/16/2023 07:23 pm »
. . . think about decision by committee. Committees are good at finding the questions to ask (and a lot of irrelevant questions) and defining responses that are unacceptable, but making decisions? LoL. Everything would boil off before the two ships reach consensus.
When you use "committees" of computers, it's called distributed computing. There has been a great deal of work done to resolve the problem of making such a system reach consensus. In the most general case, this is a fiendishly difficult problem. Algorithms like Paxos are used to solve it, and they are not easy to wrap your head around.

They also tend to be relatively slow, so you normally only use these to let a set of contending processors elect a leader. For example, when I was at Microsoft on the project now called Bing, we had to coordinate thousands of servers which individually had half-lives of a year or so. To oversimplify a bit, we used Paxos to let them elect a leader, and, if the leader failed, to replace it. For all the problems we had with Bing over the years, Paxos never failed us. Individual servers failed, but the ensemble was immortal.

With one or more Starships trying to do formation flying, it doesn't seem like there would be all that many processors involved, so something like Paxos would probably be overkill, but it proves there is at least a solution that is known to work.

As you said, figuring out which node is authoritative is an extensively solved problem.

What's considerably more difficult is the distributed control problem.  The difference between a properly controlled system and one that isn't is often determined by command and feedback lag.  That lag may often be determined by how many layers of mediation the control loop has to go through to execute a command.

If you can get a master on one Starship to directly control thrusters and read sensors on the other Starship, without having a slaved controller to mediate the commands, the control loop can be tightened up substantially.  But you need to have a very good handle on things like dropped packets and failover for that to be a viable strategy.

There was a discussion over on the Artemis thread about the Gateway Docking System Specification using time-triggered ethernet, which allows a synchronous, congestion-free channel to co-exist with vanilla switched ethernet.  Something like that would be a key enabler in letting one master reach deep into the I/O network of another spacecraft to shorten control lags.

I still think formation flying is nuts.  But the same problem applies to pairs of Starships that are docked and need to coordinate ullage and attitude burns.

Offline edzieba

  • Virtual Realist
  • Senior Member
  • *****
  • Posts: 6832
  • United Kingdom
  • Liked: 10454
  • Likes Given: 48
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2150 on: 03/16/2023 09:48 pm »
Why are people acting like Quorum computing (byzantine fault tolerant decisionmaking using multiple parallel systems) is not decades old and already in active use on Dragon - among many other non-SpaceX uses? Don't reinvent the wheel.

Offline InterestedEngineer

  • Senior Member
  • *****
  • Posts: 2760
  • Seattle
  • Liked: 2127
  • Likes Given: 3481
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2151 on: 03/16/2023 11:27 pm »
Do flocks of geese fly together by controlling each other or by having a central authority control them all?

No, they follow the vortices of the goose in front of them.   That in turn naturally makes a V formation.

No reason why such emergent behavior can't be done for mating fuel tanks in orbit.  The math for this is still a bit obscure but I bet SpaceX knows it.

Offline OTV Booster

  • Senior Member
  • *****
  • Posts: 5429
  • Terra is my nation; currently Kansas
  • Liked: 3750
  • Likes Given: 6479
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2152 on: 03/18/2023 07:13 pm »
. . . think about decision by committee. Committees are good at finding the questions to ask (and a lot of irrelevant questions) and defining responses that are unacceptable, but making decisions? LoL. Everything would boil off before the two ships reach consensus.
When you use "committees" of computers, it's called distributed computing. There has been a great deal of work done to resolve the problem of making such a system reach consensus. In the most general case, this is a fiendishly difficult problem. Algorithms like Paxos are used to solve it, and they are not easy to wrap your head around.

They also tend to be relatively slow, so you normally only use these to let a set of contending processors elect a leader. For example, when I was at Microsoft on the project now called Bing, we had to coordinate thousands of servers which individually had half-lives of a year or so. To oversimplify a bit, we used Paxos to let them elect a leader, and, if the leader failed, to replace it. For all the problems we had with Bing over the years, Paxos never failed us. Individual servers failed, but the ensemble was immortal.

With one or more Starships trying to do formation flying, it doesn't seem like there would be all that many processors involved, so something like Paxos would probably be overkill, but it proves there is at least a solution that is known to work.

As you said, figuring out which node is authoritative is an extensively solved problem.

What's considerably more difficult is the distributed control problem.  The difference between a properly controlled system and one that isn't is often determined by command and feedback lag.  That lag may often be determined by how many layers of mediation the control loop has to go through to execute a command.

If you can get a master on one Starship to directly control thrusters and read sensors on the other Starship, without having a slaved controller to mediate the commands, the control loop can be tightened up substantially.  But you need to have a very good handle on things like dropped packets and failover for that to be a viable strategy.

There was a discussion over on the Artemis thread about the Gateway Docking System Specification using time-triggered ethernet, which allows a synchronous, congestion-free channel to co-exist with vanilla switched ethernet.  Something like that would be a key enabler in letting one master reach deep into the I/O network of another spacecraft to shorten control lags.

I still think formation flying is nuts.  But the same problem applies to pairs of Starships that are docked and need to coordinate ullage and attitude burns.
Yeah, formation flying is one screwup from LoM. It's necessary until the two ships are lashed up, but no further. IMO, best if one ship autonomously holds position while the other maneuvers to lash up.


I initially thought that the depot would best take the active role but if they use CMG's this might not be true. There is danger of RCS impingement. There's no point in putting CMG's on anything but the depot so it would be in the best position to react to any impingement from the other, maneuvering, ship.


Once things are lashed up and coms latency becomes important it's essentially a point to point connection. If each ship controls its own hardware the com link would be unrouted and only pass instructions like "rotate 2degrees Y+. NETBIOS over ARCnet? It'd be PDQ.
We are on the cusp of revolutionary access to space. One hallmark of a revolution is that there is a disjuncture through which projections do not work. The thread must be picked up anew and the tapestry of history woven with a fresh pattern.

Offline OTV Booster

  • Senior Member
  • *****
  • Posts: 5429
  • Terra is my nation; currently Kansas
  • Liked: 3750
  • Likes Given: 6479
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2153 on: 03/18/2023 07:15 pm »
Do flocks of geese fly together by controlling each other or by having a central authority control them all?

No, they follow the vortices of the goose in front of them.   That in turn naturally makes a V formation.

No reason why such emergent behavior can't be done for mating fuel tanks in orbit.  The math for this is still a bit obscure but I bet SpaceX knows it.
Get back with us when geese start mating on the fly :D


edit: that would be insertive behavior.
« Last Edit: 03/18/2023 07:17 pm by OTV Booster »
We are on the cusp of revolutionary access to space. One hallmark of a revolution is that there is a disjuncture through which projections do not work. The thread must be picked up anew and the tapestry of history woven with a fresh pattern.

Offline TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4911
  • Tampa, FL
  • Liked: 3649
  • Likes Given: 684
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2154 on: 03/18/2023 09:08 pm »
Once things are lashed up and coms latency becomes important it's essentially a point to point connection. If each ship controls its own hardware the com link would be unrouted and only pass instructions like "rotate 2degrees Y+. NETBIOS over ARCnet? It'd be PDQ.

Jeez, you must be as old as I am.  The 80's called and they want their PHY and transport API back.  (I wrote an ARCnet driver for CP/M, and I implemented a NetBIOS that used an XNS transport.  How's that for a geezer smackdown?)

Seems like everything's switched ethernet today, and there's this time-triggered ethernet which will provide isochronous performance.

But I don't think you can message something like "rotate x degrees".  First of all, that command doesn't mean anything if the other ship is rotating x degrees at the same time.  Second of all, you need closed-loop control with a very, very short delay between sensor input and thruster output.  Otherwise, you'll oscillate, which consumes lots of prop if you're lucky and kills you if you're unlucky.

This is why I was suggesting that, while distributed quorum-sensing is a necessary condition, I doubt it's sufficient.  If I were doing this, I'd use quorum-sensing to designate a master GN&C CPU to seize control of the relevant I/O strings on both spacecraft, and to read sensors and command thrusters as if it were all one big system.

I don't know how tight the control loop needs to be, though.  If it's ~100ms, you can pretty much do anything you want.  But if it's <1ms, dropped packets (not an uncommon occurrence in a noisy environment) can make things weird.

Offline TomH

  • Senior Member
  • *****
  • Posts: 3081
  • Vancouver, WA
  • Liked: 2046
  • Likes Given: 1015
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2155 on: 03/20/2023 12:34 am »
IIRC, STS had 5 computers. Four were similar and worked in concert. If there was no consensus, decision making was shifted to the 5th computer which was dissimilar and completely independent. I am sure someone else will have better recall than I.

Offline OTV Booster

  • Senior Member
  • *****
  • Posts: 5429
  • Terra is my nation; currently Kansas
  • Liked: 3750
  • Likes Given: 6479
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2156 on: 03/20/2023 01:38 am »
Once things are lashed up and coms latency becomes important it's essentially a point to point connection. If each ship controls its own hardware the com link would be unrouted and only pass instructions like "rotate 2degrees Y+. NETBIOS over ARCnet? It'd be PDQ.

Jeez, you must be as old as I am.  The 80's called and they want their PHY and transport API back.  (I wrote an ARCnet driver for CP/M, and I implemented a NetBIOS that used an XNS transport.  How's that for a geezer smackdown?)

Seems like everything's switched ethernet today, and there's this time-triggered ethernet which will provide isochronous performance.

But I don't think you can message something like "rotate x degrees".  First of all, that command doesn't mean anything if the other ship is rotating x degrees at the same time.  Second of all, you need closed-loop control with a very, very short delay between sensor input and thruster output.  Otherwise, you'll oscillate, which consumes lots of prop if you're lucky and kills you if you're unlucky.

This is why I was suggesting that, while distributed quorum-sensing is a necessary condition, I doubt it's sufficient.  If I were doing this, I'd use quorum-sensing to designate a master GN&C CPU to seize control of the relevant I/O strings on both spacecraft, and to read sensors and command thrusters as if it were all one big system.

I don't know how tight the control loop needs to be, though.  If it's ~100ms, you can pretty much do anything you want.  But if it's <1ms, dropped packets (not an uncommon occurrence in a noisy environment) can make things weird.
OMG! CPM Arcnet? I yield. You be the mastah of the geezers. What are the chances that what we been thinking was a slot for ejecting starlinks is really where they insert the boot floppy?

And I'm sorry, but a physical layer that is not probabilistic ain't ethernet. Calling it ethernet is just marketing bs and is disrespectful to an honest data storm.

I've spent the last week resurrecting a 98SE tower. The only I/O was an IDE HDD with a USB/IDE dongle for the laptop end, then plug it into the tower on the second IDE channel to copy the files it needs. Putting Lantastic on it is tempting but it's got nothing to talk to.

I think the project has been getting to me.


Edit: know anybody who needs a lightly used Osborn?
« Last Edit: 03/20/2023 01:41 am by OTV Booster »
We are on the cusp of revolutionary access to space. One hallmark of a revolution is that there is a disjuncture through which projections do not work. The thread must be picked up anew and the tapestry of history woven with a fresh pattern.

Offline TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4911
  • Tampa, FL
  • Liked: 3649
  • Likes Given: 684
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2157 on: 03/20/2023 02:18 am »
IIRC, STS had 5 computers. Four were similar and worked in concert. If there was no consensus, decision making was shifted to the 5th computer which was dissimilar and completely independent. I am sure someone else will have better recall than I.

The crew had to manually switch to the backup if things went horribly wrong.  The idea was that a completely different implementation was unlikely to have the same bug in the same place.

The set of 4 identical CPUs would all receive the same input, compute the outputs, and exchange state vectors every 40ms.  If one of the state vectors didn't agree with the others, the other 3 would take over the bad one's output duties.  Crude but effective.

Offline OTV Booster

  • Senior Member
  • *****
  • Posts: 5429
  • Terra is my nation; currently Kansas
  • Liked: 3750
  • Likes Given: 6479
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2158 on: 03/20/2023 02:23 am »
Once things are lashed up and coms latency becomes important it's essentially a point to point connection. If each ship controls its own hardware the com link would be unrouted and only pass instructions like "rotate 2degrees Y+. NETBIOS over ARCnet? It'd be PDQ.

Jeez, you must be as old as I am.  The 80's called and they want their PHY and transport API back.  (I wrote an ARCnet driver for CP/M, and I implemented a NetBIOS that used an XNS transport.  How's that for a geezer smackdown?)

Seems like everything's switched ethernet today, and there's this time-triggered ethernet which will provide isochronous performance.

But I don't think you can message something like "rotate x degrees".  First of all, that command doesn't mean anything if the other ship is rotating x degrees at the same time.  Second of all, you need closed-loop control with a very, very short delay between sensor input and thruster output.  Otherwise, you'll oscillate, which consumes lots of prop if you're lucky and kills you if you're unlucky.

This is why I was suggesting that, while distributed quorum-sensing is a necessary condition, I doubt it's sufficient.  If I were doing this, I'd use quorum-sensing to designate a master GN&C CPU to seize control of the relevant I/O strings on both spacecraft, and to read sensors and command thrusters as if it were all one big system.

I don't know how tight the control loop needs to be, though.  If it's ~100ms, you can pretty much do anything you want.  But if it's <1ms, dropped packets (not an uncommon occurrence in a noisy environment) can make things weird.
In a more serious vein, the data environment before and after lash up are very different. Pre lash up, ISTM that keeping one ship passive while the other maneuvers keeps the risk low. Passive in this case doesn't mean dead. It means holding attitude but not otherwise maneuvering.


After lash up the rules change. Both ships need to (probably) work together for ullage settling and attitude control. But...


If the depot has CMG's and can thrust off axis with TVC on the settling engine, it should be able to handle everything. And, once they're lashed up they can have a physical low noise data connection. As you suggested, the second ships sensors would become an extension of the depot. Control systems could be tied in too if necessary.


Some questions:
- What are the chances the sensors and controls on SS are a data buss sharing network?
- Can off axis thrust be made a virtue during transfer? It imposes a certain type of order on slosh.
We are on the cusp of revolutionary access to space. One hallmark of a revolution is that there is a disjuncture through which projections do not work. The thread must be picked up anew and the tapestry of history woven with a fresh pattern.

Offline TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4911
  • Tampa, FL
  • Liked: 3649
  • Likes Given: 684
Re: Starship On-orbit refueling - Options and Discussion
« Reply #2159 on: 03/20/2023 05:46 pm »
In a more serious vein, the data environment before and after lash up are very different. Pre lash up, ISTM that keeping one ship passive while the other maneuvers keeps the risk low. Passive in this case doesn't mean dead. It means holding attitude but not otherwise maneuvering.

After lash up the rules change. Both ships need to (probably) work together for ullage settling and attitude control. But...

If the depot has CMG's and can thrust off axis with TVC on the settling engine, it should be able to handle everything. And, once they're lashed up they can have a physical low noise data connection. As you suggested, the second ships sensors would become an extension of the depot. Control systems could be tied in too if necessary.

Some questions:
- What are the chances the sensors and controls on SS are a data buss sharing network?
- Can off axis thrust be made a virtue during transfer? It imposes a certain type of order on slosh.

The data bus is likely 1000BaseT ethernet.  I assume that it's switched, because everything is these days.  So it should be quite easy to make one network out of two Starships.

I obviously don't know the exact architecture of the network.  Never stops me from guessing, though.  For long runs (e.g. across the prop tanks), I'd use redundant wiring, with switches at either end.  From those switches, which no doubt have all sorts of vibration and noise hardening, you'd have fairly short runs to other distribution switches, which would feed individual engine controllers, gimbals, thrusters, heaters, coolers, IMUs, CMGs, etc.

The trick would be to minimize mass.  A switch almost certainly weighs less than two 20m Cat 6 cables, but it probably doesn't weigh less than 3 pairs of 2m cables.  No doubt somebody spent a lot of time of topology.  But once you get everything wired up, it's... just another LAN.  Give each Starship its own private subnet and they'll happily talk to one another.  Then it's just a question of how you allocated the computational resources.

I don't think off-axis thrust is ever a virtue.  But with full access to all the ullage thrusters, it's not difficult to keep things from rotating.  Even if the depot has CMGs, I don't think you want to load them as much as they'd have to be loaded to balance a 30-60 minute ullage burn during transfer.

BTW, here's the wikipedia article on time-triggered ethernet.  It's not really synchronous, but it's effectively isochronous for certain traffic types.  Kinda clever.  This is supposed to be what's used in the Gateway Docking System Specification, which is pressure- and latch-compatible with IDSS, but has different electrical and fluid connectors.

Tags: HLS 
 

Advertisement NovaTech
Advertisement
Advertisement Margaritaville Beach Resort South Padre Island
Advertisement Brady Kenniston
Advertisement NextSpaceflight
Advertisement Nathan Barker Photography
1