<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>I'd expect higher saturation to be associated with the use of
fewer satellites per user terminal, and therefore lower power use.</p>
<p>Similarly, I'd expect proximity to gateways to be associated with
higher power use.<br>
</p>
<p>What leads me to this impression? <br>
</p>
<p>Essentially, inter-satellite linking isn't yet in widespread use
for Starlink, so most users at this point still use a bent-pipe
arrangement
terminal<->satellite<->gateway<->Internet.</p>
<p>This requires the satellite to be in view of both terminal and
gateway. There is, however, no reason why a user's packets could
not travel via a diversity of satellites. The only requirement for
this arrangement is that the satellites used must be in the
intersection of the set of satellites that the terminal can see
and the set of satellites that the gateway can see. <br>
</p>
<p>What makes me think that this is actually happening? I'm in a low
saturation cell close to multiple gateways and partial obstruction
of the southern sky (which dishy uses in the southern hemisphere).
So whatever satellite my dishy sees, the gateways also see (more
or less), but the number of satellites I see is constrained by the
partial obstruction, so jumps up and down over short periods of
time as the satellites move in and out of view for me.<br>
</p>
<p>When I look at achievable rates with the likes of speedtest.net
then I see huge jumps over relatively short periods of time. 20-30
Mb/s down one moment, 160+ Mb/s in the next run. This is exactly
what I'd expect if dishy moves from a set of satellites with
plenty of competition from neighbouring rural regions (e.g.,
satellites south-east of Auckland) to a larger set predominantly
over the Tasman Sea, where there are no users. I'm simplifying
here.</p>
<p>So if you happen to be a nerd in a fibre-connected and
-penetrated city surrounded by gateways, you should see higher
power use as Starlink wants you to have the maximum rate possible
and will let you access whichever birds are available during the
current time period. If you're in the wap-waps with your nearest
gateway 100's of kilometres away (or miles for youse Americans and
Brits, we're talking ballpark here ;-)), then the number of
satellites you see that can relay to gateways for you should be
smaller on average. You would be facing stiff competition for
their capacity from your neighbours down the road. That would give
you less chance to transmit, and hence lower power use. Note: A
mitigating factor here could also be that the beams you need to
communicate with these relaying satellites from your dishy might
be further off bore than in the former case, which would require a
little extra power to make up for longer path and lower dishy
aperture.</p>
<p>Hope that makes sense?<br>
</p>
<div class="moz-cite-prefix">On 18/02/2023 4:43 am, Michael
Richardson wrote:<br>
</div>
<blockquote type="cite" cite="mid:20200.1676648584@localhost">
<br>
Ulrich Speidel via Starlink <a class="moz-txt-link-rfc2396E" href="mailto:starlink@lists.bufferbloat.net"><starlink@lists.bufferbloat.net></a>
wrote:<br>
> * Whether you consider your cell Starlink virgin territory or
close to<br>
> subscriber saturation (<a href="https://www.starlink.com/map" moz-do-not-send="true">https://www.starlink.com/map</a> might
help<br>
> determine that - if it's light blue, it's likely the former,
if it's<br>
> "waitlist" blue but surrounded by light blue areas, or rural
and<br>
<br>
What's the expected corrolation?<br>
Higher saturation => higher current? Or the opposite?<br>
<br>
</blockquote>
<pre class="moz-signature" cols="72">--
****************************************************************
Dr. Ulrich Speidel
School of Computer Science
Room 303S.594 (City Campus)
The University of Auckland
<a class="moz-txt-link-abbreviated" href="mailto:u.speidel@auckland.ac.nz">u.speidel@auckland.ac.nz</a>
<a class="moz-txt-link-freetext" href="http://www.cs.auckland.ac.nz/~ulrich/">http://www.cs.auckland.ac.nz/~ulrich/</a>
****************************************************************
</pre>
</body>
</html>