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:
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?
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/ ****************************************************************