[Starlink] Dishy GRPC obstruction maps

[Starlink] Dishy GRPC obstruction maps

[Ulrich Speidel]

[-- Attachment #1: Type: text/plain, Size: 4658 bytes --]

I've been playing a little bit with these:

https://github.com/sparky8512/starlink-grpc-tools

More specifically, I've been playing with the python script that's 
getting the obstruction map here. This grabs an array of 123 row tuples 
with 123 floating point number column entries each, which represent SNR 
(signal to noise ratio) data, with the row and column indices of the 
data structure being 2D coordinates of the direction in which this data 
was observed. A value of -1 meaning that Dishy hasn't ever seen a 
satellite in this direction, actual signal strengths are coded as values 
between 0.0 and 1.0. You can output these as PNGs as well, like here 
(with a slightly changed colour scheme):

What you are looking at is a screenshot (so not exactly 123x123 but very 
close), with white pixels corresponding to good signal and anything 
blueish to impaired signal, and anything black to no signal. North is 
top, west is left and east is right. You're looking at the corner of my 
house as seen by Dishy on my deck, the flattish bit on the left is a 
wooden trellis getting in the way, and the light blue line crossing the 
white top part is the aluminium front bar of my awning (the awning 
fabric appears to be transparent to the RF signal).

My ultimate goal here is to be able to identify which satellite Dishy is 
currently talking to, something the grpc interface doesn't seem to 
reveal directly (anymore). This is of some interest in order to see 
where signals enter the Starlink network, which ground stations the 
satellite may relay to in bent pipe mode, and perhaps for an educated 
guess as to which ISL hops it's taking.

I'm trying to do this essentially by comparing two successive retrievals 
of this map and detecting which entry has changed. This is the easy part.

The hard part is trying to figure out which satellite this corresponds 
to. Essentially, the idea is to translate this pixel data into a unit 
vector pointing at the satellite, and then compare that with the unit 
vectors from Dishy's location pointing at the thousands of Starlink sats 
up there, and picking the one pair with the smallest angle. All this 
takes conceptually are a few coordinate transforms to get everything 
into the same coordinate system, with sat positions computed from NORAD 
two line elements.

My initial thought was that:

 1. Index coordinate (62,62) in the SNR data matrix corresponds to a
    satellite that sits on the Dishy surface normal.
 2. Indices minus 62 correspond to some sort of Cartesian x-y coordinate
    that should let me derive a unit vector for the direction to the
    satellite in a polar coordinate system based on Dishy's surface and
    the surface normal.
 3. That then needs transforming into a coordinate system based on
    Dishy's location, removing Dishy orientation in the step. Dishy
    location and orientation are kindly available from Dishy itself via
    grpc.
 4. Coming the other way, two line elements need to be turned into
    global coordinates for satellites at the current time, and these
    need to be turned into local coordinates in the system we're
    transforming into under 3 above.

The crux is at step 1 and 2. If the assumption under 1 is correct and we 
assume that the scales in row and column direction are the same, getting 
at the azimuth is easy. But what does the distance of an entry (pixel) 
to the centre of the map represent?

  * A linear function of the elevation angle?
  * A cosine projection of the elevation angle?
  * Would a map position in the middle of each map edge represent an
    elevation of 0 or, given the much rumoured phased array "cone" of
    100 degrees, an angle of 40 degrees over Dishy surface?
  * Something else?

But I'm not even sure that the assumption under 1 is correct. Note how 
the area with valid SNR values in the map above is slightly elliptic and 
offset a bit towards the bottom? This can't be due to Dishy's geometry 
as the long dimension of it is top to bottom (north to south) rather 
than east to west. Could this already be a projection into 
the coordinate system based on Dishy's location, such that (62,62) is 
straight up from the ground?

Anyone got any insights on this?

Thanks muchly in advance.

Ulrich

-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************



[-- Attachment #2.1: Type: text/html, Size: 5802 bytes --]

[-- Attachment #2.2: nt53GBZYWHk9iG0c.png --]
[-- Type: image/png, Size: 15679 bytes --]

Re: [Starlink] Dishy GRPC obstruction maps

[Nitinder Mohan]

[-- Attachment #1: Type: text/plain, Size: 5644 bytes --]

Hi Ulrich,

I suggest you take a look into these recent publications. They have used used obstruction maps to get an idea about which satellite you are currently connecting to. 

[1] https://dl.acm.org/doi/abs/10.1145/3624354.3630586
[2] https://arxiv.org/abs/2306.07469

We are currently building a reusable framework that maps the obstruction map data with TLE data and gets a (somewhat more) accurate estimate of currently connected satellite — pretty much on the same lines as what you intend to do. However, the work is still underway and I am to chat more if you want to align efforts. 

Thanks and Regards

Nitinder Mohan
Technical University Munich (TUM)
https://www.nitindermohan.com/

From: Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net>
Reply: Ulrich Speidel <u.speidel@auckland.ac.nz>
Date: 25. January 2024 at 02:27:44
To: starlink@lists.bufferbloat.net <starlink@lists.bufferbloat.net>
Subject:  [Starlink] Dishy GRPC obstruction maps

I've been playing a little bit with these:

https://github.com/sparky8512/starlink-grpc-tools

More specifically, I've been playing with the python script that's getting the obstruction map here. This grabs an array of 123 row tuples with 123 floating point number column entries each, which represent SNR (signal to noise ratio) data, with the row and column indices of the data structure being 2D coordinates of the direction in which this data was observed. A value of -1 meaning that Dishy hasn't ever seen a satellite in this direction, actual signal strengths are coded as values between 0.0 and 1.0. You can output these as PNGs as well, like here (with a slightly changed colour scheme):



What you are looking at is a screenshot (so not exactly 123x123 but very close), with white pixels corresponding to good signal and anything blueish to impaired signal, and anything black to no signal. North is top, west is left and east is right. You're looking at the corner of my house as seen by Dishy on my deck, the flattish bit on the left is a wooden trellis getting in the way, and the light blue line crossing the white top part is the aluminium front bar of my awning (the awning fabric appears to be transparent to the RF signal).

My ultimate goal here is to be able to identify which satellite Dishy is currently talking to, something the grpc interface doesn't seem to reveal directly (anymore). This is of some interest in order to see where signals enter the Starlink network, which ground stations the satellite may relay to in bent pipe mode, and perhaps for an educated guess as to which ISL hops it's taking.

I'm trying to do this essentially by comparing two successive retrievals of this map and detecting which entry has changed. This is the easy part.

The hard part is trying to figure out which satellite this corresponds to. Essentially, the idea is to translate this pixel data into a unit vector pointing at the satellite, and then compare that with the unit vectors from Dishy's location pointing at the thousands of Starlink sats up there, and picking the one pair with the smallest angle. All this takes conceptually are a few coordinate transforms to get everything into the same coordinate system, with sat positions computed from NORAD two line elements.

My initial thought was that:

Index coordinate (62,62) in the SNR data matrix corresponds to a satellite that sits on the Dishy surface normal.
Indices minus 62 correspond to some sort of Cartesian x-y coordinate that should let me derive a unit vector for the direction to the satellite in a polar coordinate system based on Dishy's surface and the surface normal.
That then needs transforming into a coordinate system based on Dishy's location, removing Dishy orientation in the step. Dishy location and orientation are kindly available from Dishy itself via grpc.
Coming the other way, two line elements need to be turned into global coordinates for satellites at the current time, and these need to be turned into local coordinates in the system we're transforming into under 3 above.
The crux is at step 1 and 2. If the assumption under 1 is correct and we assume that the scales in row and column direction are the same, getting at the azimuth is easy. But what does the distance of an entry (pixel) to the centre of the map represent?

A linear function of the elevation angle?
A cosine projection of the elevation angle?
Would a map position in the middle of each map edge represent an elevation of 0 or, given the much rumoured phased array "cone" of 100 degrees, an angle of 40 degrees over Dishy surface?
Something else?
But I'm not even sure that the assumption under 1 is correct. Note how the area with valid SNR values in the map above is slightly elliptic and offset a bit towards the bottom? This can't be due to Dishy's geometry as the long dimension of it is top to bottom (north to south) rather than east to west. Could this already be a projection into the coordinate system based on Dishy's location, such that (62,62) is straight up from the ground?

Anyone got any insights on this?

Thanks muchly in advance.

Ulrich

--  
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************



_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

[-- Attachment #2.1: Type: text/html, Size: 8682 bytes --]

[-- Attachment #2.2: part1.n0Nald5Y.xOSpw9CF@auckland.ac.nz --]
[-- Type: application/octet-stream, Size: 15679 bytes --]