Inter-satellite link model

[bmatthiesen]

For determining inter-satellite link (ISL) connectivity, the line of sight should not go below the Thermosphere (starts at 80km above the surface). Communication might also be possible in other cases but this would require much more complicated modeling.

Reference: Network topology design at 27,000 km/hour

[gomezzz]

@GabrieleMeoni @johanos1 This we can easily implement but it is a bit question whether we want to do it with a long- or short-term perspective, I think?

Short-term Option

Allow users to specify a "blocking" radius around the Earth (so, to just add some value to the current 6371km sphere blocking comms)

Long-term Option

Allows users to specify a generic mesh or scitkit-spatial object for this. Line of sight can than be computed with a ray-mesh intersection algorithm e.g.. This is interesting for scenarios around irregular bodies like asteroids / comets anyways.

I'd opt for the short-term option atm?

[johanos1]

I agree with he short term option for now.

[GabrieleMeoni]

I also agree with the short-term view for the moment. This can be made more complex in the future.

[gomezzz]

@GabrieleMeoni @johanos1 This brings up another question. Rn we would also be considering the same sphere for computing eclipses. Should we or should they be decoupled? 🤔

[gomezzz]

For now, this also affects the thermal and charging models.

@bmatthiesen Feel free to also comment here or on #152 if you have thoughts and whether this is in line with what you were looking for.

[bmatthiesen]

Thanks for looking into this so quickly!

I also agree with the short term solution. This whole thing does not matter for comets or similar, so there is no reason to have a safe radius around these bodies.

However, I consider this setting highly link specific. For example, this is completely irrelevant for ground to satellite links. Certain types of inter-satellite links might also be immune to these issues. In other words, this is a very simple approach to make ISLs work so it might be worth introducing different link types and associating this safe radius only with certain link types.

[gomezzz]

| I also agree with the short term solution.

👍

This whole thing does not matter for comets or similar, so there is no reason to have a safe radius around these bodies.

It does I think, we have some projects in that direction for swarm observations of comets etc. where they communicate with each other. But this is not urgent for the moment.

However, I consider this setting highly link specific. For example, this is completely irrelevant for ground to satellite links.

Won't be considered for them in current implementation of PASEOS. The ground station communication is only based on angle above the horizon atm.

Certain types of inter-satellite links might also be immune to these issues.

Yea, I think to some degree what we may want to do in the future is the allowing users to specify a custom function defined by them that gives availability ( + strength etc.) of links. In the long run, it might be most practical to have a rudimentary option in PASEOS but provide a simple interface for users to define something more complicated that matches their needs?

[gomezzz]

For the moment, can be achieved #166 , see also https://github.com/aidotse/PASEOS#via-custom-properties