sebsebmc / starlink-coverage Goto Github PK

Noticing quite a large discrepancy amongst cells between your map and the starlink.com/map could you advise?

Due to the initial phase of satellites not communicating between satellites, yet... In order to send and receive data from a user terminal, the satellite that your user terminal communicates with must also see a ground station at the same time. Therefore, what is the coverage pattern of the satellites, while being able to contact a ground station and the target grid section at the same time? A checkbox perhaps, enable ground station data coverage?

As you note in README.md, the minimum elevation angle on the initial 1,584-satellite shell has been approved by the FCC at 25%, moving to 40% once the entire 4,409-satellite system is built out. See https://licensing.fcc.gov/myibfs/download.do?attachment_key=1877671. This modification (SAT-MOD-20190830-00087) was approved on December 19, 2019.

On April 17, 2020, SpaceX applied for a number of changes (SAT-MOD-20200417-00037), including asking for minimum elevation angles down to 25% on most of the constellation, but down to 5% on the high inclination portions. This application has not yet been approved by the FCC. See https://licensing.fcc.gov/myibfs/download.do?attachment_key=2274316.

As far as I know, the V-band constellation minimum elevation angle has not been changed.

The 30k-satellite additional constellation application (SAT-LOA-20200526-00055) also is asking for minimum elevation angles down to 25% on most of the constellation, but down to 5% on the high inclination portions . See https://licensing.fcc.gov/myibfs/download.do?attachment_key=2378671.

Thanks for this very nice visualization!

There are a couple of statistics that should be relatively easy to develop into this kind of simulation. This issue will track ideas until they start to get broken out into their own issues.

• Calculating average time between gaps. At higher resolutions this will become an average of averages which is unfortunate. This should give an idea of how spotty/intermittent service is.

Hi,
Thank you for your this.

Just wanted to ask, what is the reason why you exclude satellites with perigee less than 540?

Regards,
Bryan

Very cool project. It would be really cool to see the number of additional satellites needed to reach 100% coverage for a particular cell. This would help me think about the time frame of when a cell would be fully covered.

When generating the full file for a day, the areas near the north and south pole never get any coverage so we need to insert those indexes into the file.

This should fill the missing parts of the visualization

If a cell gets ~100% uptime the cell outline could be changed to gold or some other color with good contrast to blue, yellow, and red. Because currently we only show resolution 2 cells and those use averages we don't expect to have any res 2 cells with 100% coverage. Maybe a 99.9% uptime would be enough to highlight?

This is more of inquiry and request for alignment depending upon the answer, but dishes are currently assigned by Starlink to a "Cell" in which they are scheduled to receive service. Does a "Cell" in this project equate to the same geological area ad Starlink maps them? and if not what data would be needed to deduce a proper alignment (aka how might one assist). Amazing project - Cheers!

Could you choose / add a license?
Thanks!

It would be beneficial to show some stats of a cell when mousing over it. This would improve things like readability of the coverage percentage, especially when over land vs water where they appear very differently due to the opacity and contrast.

Hi - love the site, but unable to tell how up to date the data being shown is. Would be great if you could add something to indicate that. Thanks!

Could we get smaller Cells so we can get more accurate coverage

Currently the data is simulated at resolution 4, and loaded at resolution 4 but for the sake of getting something out the door I render at resolution 2 right now. I want to add a slider or calculate based on the render distance (because Cesium doesn't have a concept of zoom levels) when to switch between rendered resolutions.

Thanks for a great effort. When using https://sebsebmc.github.io/starlink-coverage/index.html on a Android tablet (Samsung Tab S6), double tab on a cell does not zoom to the higher resolution as indicated in text.
Thanks

Currently there are a number of satellites that are raising orbits or deorbiting. Those should not be used when calculating coverage. Someone recommended looking at the perigee and using a cutoff altitude to ignore satellites that are too low.

Using 25 degrees
Using the newest Microsoft Edge browser.

Cell 822d47f for instance says full coverage but is lacking a star.

This cell is covered on average 1440 minutes of 1440 for the day.
This is approximately 100% of the day.

Currently I manually set the date and by hand start 4 python instances of main.py to generate the partial coverage files. Then I manually run the merge and push the new coverage file to GitHub. The process should be turned into a bash script with configurable number of processes and at least do the merge automatically at the end.

For historical purposes I would like to keep the old coverage files, so the final coverage file names should contain the date they were generated for.

Is there is a way for identifying cell IDs that are within US territory? I am trying to calculate the % coverage for the cells within the US territory.
Do you think the global performance (% coverage) is similar to the performance of the cells in the US territory?

Thanks!!

The stars representing that a area has 100% coverage only show when you set the a minimum angle to load the dataset to 25 degrees, when you set that to 35 degrees it doesn't show any stars where it should show them.

De first picture shows the 35 degrees option, and the second picture shows the 25 degrees option

Thanks anyway for the awesome website!

At the IDL the polygon passed to H3's polyfill will return no results. This is a documented issue with H3 here: uber/h3#210

In order to fix this, when H3 returns 0 cells, its most likely because the polygon crosses the antimeridian and so the polygon needs to be split into 2 polygons with the antimeridian as the edge between the two.

There are a lot of ways to compress the file to make it smaller and also to reduce the memory usage of the coverage data when loaded.

In the main.py the failures_url link seems not working. There are a few URL redirects and it seems the data is not downloaded. Here is the output when I run the main.py:

Loaded 2568 satellites
Traceback (most recent call last):
File "main.py", line 201, in
op_sats = filter_sats(sats)
File "main.py", line 61, in filter_sats
name = row{'NAME'].strip()
KeyError: 'NAME'

Could you let me know how to fix this problem?
Thanks a lot for sharing the code and thanks for your support.

Thanks!!

Currently I am trying to run your program to generate the data using the scripts you provided, gen_cov.sh, my first remark is that the encoding for end-of-line is not unix standard in your python sources, i.e. DOS instead of Unix. Second, I ran in an issue when running the forementioned script : sh gen_cov.py. Here's the outcome :

Sat 02 Jan 2021 05:58:48 PM CET
Loaded 897 satellites
Filtered to 659 operational satellites
2020-07-25T00:00:00Z
Traceback (most recent call last):
  File "/tmp/starlink-coverage/./main.py", line 246, in <module>
    angle = calcCapAngle(sat.elevation.km, MIN_TERMINAL_ANGLE_DEG)
  File "/tmp/starlink-coverage/./main.py", line 100, in calcCapAngle
    eta_FOV = math.asin((math.sin(epsilon + RIGHT_ANGLE)
ValueError: math domain error
Loaded 897 satellites
Filtered to 659 operational satellites
2020-07-25T18:00:00Z
Traceback (most recent call last):
  File "/tmp/starlink-coverage/./main.py", line 246, in <module>
    angle = calcCapAngle(sat.elevation.km, MIN_TERMINAL_ANGLE_DEG)
  File "/tmp/starlink-coverage/./main.py", line 100, in calcCapAngle
    eta_FOV = math.asin((math.sin(epsilon + RIGHT_ANGLE)
ValueError: math domain error
Loaded 897 satellites
Filtered to 659 operational satellites
2020-07-25T12:00:00Z
Traceback (most recent call last):
  File "/tmp/starlink-coverage/./main.py", line 246, in <module>
    angle = calcCapAngle(sat.elevation.km, MIN_TERMINAL_ANGLE_DEG)
  File "/tmp/starlink-coverage/./main.py", line 100, in calcCapAngle
    eta_FOV = math.asin((math.sin(epsilon + RIGHT_ANGLE)
ValueError: math domain error
Loaded 897 satellites
Filtered to 659 operational satellites
2020-07-25T06:00:00Z
Traceback (most recent call last):
  File "/tmp/starlink-coverage/./main.py", line 246, in <module>
    angle = calcCapAngle(sat.elevation.km, MIN_TERMINAL_ANGLE_DEG)
  File "/tmp/starlink-coverage/./main.py", line 100, in calcCapAngle
    eta_FOV = math.asin((math.sin(epsilon + RIGHT_ANGLE)
ValueError: math domain error
mv: cannot stat 'h3_4_cov_full.txt': No such file or directory
  File "/tmp/starlink-coverage/./merge_cover.py", line 36
    res4_cells = h3.h3_to_children(base_cell, 4)
IndentationError: unexpected indent

Could you help me troubleshoot the situation?