From: David Lang <david@lang.hm>
To: Ulrich Speidel <u.speidel@auckland.ac.nz>
Cc: Mike Puchol <mike@starlink.sx>,
starlink@lists.bufferbloat.net,
Michael Richardson <mcr@sandelman.ca>, David Lang <david@lang.hm>
Subject: [Starlink] Re: Starlink and Iran
Date: Wed, 28 Jan 2026 02:53:14 -0700 (MST) [thread overview]
Message-ID: <89q404n0-7205-86o5-p825-o6o140619o6n@ynat.uz> (raw)
In-Reply-To: <902920e5-3c86-49e9-9316-fcb2416ee6f2@auckland.ac.nz>
rather than looking at it as 'every 3db lets you add 1 bit/s/Hz', look at it as
'every 3db lets you double the number of beams covering the area.
With enough satellites, it's easy to have multiple satellites in view at
sufficiently different angles. They have 10k satellites up now and were
providing coverage with something around 1k satellites.
it would be interesting to learn the density of users in different countries. I
would not be surprised to learn that the US has far more users/area than other
countries, so if Starlink limits itself to the article 21 emissions outside the
US but goes over the limits in the US, why would it be a problem?
David Lang
On Wed, 28 Jan 2026, Ulrich Speidel wrote:
> Date: Wed, 28 Jan 2026 22:05:24 +1300
> From: Ulrich Speidel <u.speidel@auckland.ac.nz>
> To: Mike Puchol <mike@starlink.sx>, starlink@lists.bufferbloat.net
> Cc: Michael Richardson <mcr@sandelman.ca>, David Lang <david@lang.hm>
> Subject: Re: [Starlink] Re: Starlink and Iran
>
> It's not that straightforward.
>
> The EPFD limits under Article 21 apply as an aggregate limit, not on a
> per-beam basis. With Nco=1, a single beam can utilise this limit. This lets
> that beam project (for v2) 64QAM, and for v1 (16QAM) as the underlying
> modulation scheme of the OFDM. But only just - the fade margin there is ~1
> dB. That gives the beam a theoretical capacity of 6 bit/s / Hz for v2 and 4
> bit/s / Hz for v1.
>
> If you use both polarisations, each beam needs to be lowered in power by half
> (3 dB), which costs 1 bit/s / Hz. So in v2, using two co-frequency beams with
> opposing polarisation gives you 2 * (6 - 1) = 10 bit/s / Hz in total for v2,
> or 2 * (4 - 1) = 6 bit/s / Hz. That's what's been possible so far.
>
> If you read 4. a. as "on the same frequency" rather than "in the same
> frequency band" and thus go to Nco=8, then that EPFD budget needs to be
> shared between the 8 beams. If that's done equally, this knocks back the
> received power per beam by 9 dB. Now, each 3 dB in power loss costs the beam
> 1 bit/s / Hz in capacity. So if these are v2 beams, you're now down to 3
> bit/s / Hz and for v1 you're at 1 bit/s / Hz. So using just one polarisation
> gives you up to 8 * 3 = 24 bit/s Hz for v2. That's a factor of 2.4 in terms
> of capacity for v2 or 4/3 for v1. The latter is a bit academic since the
> grant is for v2 only.
>
> So it's not nothing, but it's not a factor of 8. The main benefit here could
> be easier compliance with the requirements of Article 22 though, so the
> factor of 2.4 could translate into something a bit higher in some practical
> situations where Article 22 currently bites first.
>
> Now we can't use the opposite polarisation of each beam here because that
> would remain a co-frequency beam and thus we'd exceed the limit of 8. If
> Starlink were to use 4 co-frequency beams of each polarisation, we'd need to
> lop off another 3 dB or 1 bit/s / Hz per beam. That would give us 16 bit/s /
> Hz across the 2 * 4 beams.
>
> Note that the satellite's beam shaping (different from beam steering) ensures
> that the footprint on the ground is more or less circular and covers the H3
> hexagon pretty much exactly, with the beam contour leaking into the adjacent
> cells, thereby ensuring that if all 8 co-frequency beams point at a cell,
> then neither this frequency (nor beams with the opposite polarisation on the
> same frequency) can be used for the cells next door.
>
> Also note that deploying that number of beams assumes that you have a
> sufficient number of spacecraft (very easy) in the right positions (much
> harder) to allow 8 beams to downlink without interfering with each other -
> you'll need significant angular separation here from the Dishy perspective.
>
> David was asking what would happen if the EPFD limits were raised. In terms
> of Article 21, my answer would by "by how much?" Every 3 dB increase would
> translate into 1 bit/s / Hz extra per beam. But quite how many such steps are
> realistic before you get to power values that are difficult to provide in
> space is another question.
>
> Sure, with Starship you could launch larger satellites. But larger satellites
> with larger panels also have a larger cross-section, and that has an impact
> on collision probabilities and so on.
>
> Another notable point is the addition of multiple frequency bands for uplink
> and for what is clearly only suitable for downlink to gateway. This indicates
> that SpaceX are feeling the need for more uplink capacity as gateways now
> don't just supply bent pipes through a single satellite but are actually feed
> points for a much larger mesh.
>
> On 28/01/2026 5:02 pm, Mike Puchol wrote:
>> One clarification, nco = 8 means 8 co-frequency beams overlapping. If you
>> have 8 different channels in Ku band, that’s a total of 64 possible beams
>> per cell. This is a huge upgrade from the original nco = 1 for user/service
>> beams (e.g. max 8 beams per cell).
>>
>> Best,
>>
>> Mike
>> On Jan 27, 2026 at 19:30 -0800, David Lang via Starlink
>> <starlink@lists.bufferbloat.net>, wrote:
>>> Ulrich Speidel wrote:
>>>
>>>> Either way, it's worth noting here that while the relationship between
>>>> transmit power and and received power is linear, the relationship between
>>>> received power and achievable bit rate is logarithmic in nature. For
>>>> those
>>>> not so mathematically inclined: Starlink is starting off with 64QAM (6
>>>> bits
>>>> per symbol) at current EPFD limits, and each extra bit beyond that
>>>> requires a
>>>> doubling of the received power. Turning up the volume is not a game you
>>>> can
>>>> stay ahead in for long, regardless of regulatory constraints.
>>>
>>> I think that the value in allowing higher radiated power at the receive
>>> end
>>> isn't to increase the bit rate from a single satellite, but to allow
>>> multiple
>>> satellites to cover the same area with the beam steering on the receiver
>>> differentiating between the satellites.
>>>
>>> allowing two satellites with significantly different angles to cover the
>>> same
>>> area allows for (close to) 2x the aggregate bandwidth to spread between
>>> all
>>> receivers in that area.
>>>
>>>> Some interesting tidbits from the grant document though:
>>>>
>>>> * 4. a. No more than 8 satellite beams "in the same frequency" (I
>>>> presume there's the word "band" missing here) into the same or
>>>> overlapping areas at a time. That means at most 8 beams per cell.
>>>
>>> if that's a step up from a single beam, that will allow for close to 8x
>>> the
>>> aggregate bandwidth.
>>>
>>> And if they can show (over time) that this doesn't cause problems, it will
>>> be
>>> reasonable to expect raising this limit over time
>>>
>>> it may be band, or it may be frequency/channel (like wifi has 3 bands,
>>> 2.4G, 5G,
>>> 6G), but 5G has many non-overlapping channels, and operating on multiple
>>> channels at the same time is quite reasonable for high-end APs
>>>
>>>> * 4. b. "SpaceX must maintain a minimum GSO arc exclusion zone of at
>>>> least four (4) degrees with respect to operational GSO satellites".
>>>> Finally a clear word?
>>>
>>> that geo exclusion has been in place for a while, but I thought it was a
>>> lot
>>> wider than 8 degrees (4 degrees to each side) I seem to remember hearing
>>> 25
>>> degrees being thrown around in discussions (I may very well be
>>> misremembering)
>>>
>>> David Lang
>>> _______________________________________________
>>> Starlink mailing list -- starlink@lists.bufferbloat.net
>>> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>
>
next prev parent reply other threads:[~2026-01-28 9:53 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <176851123059.1249.8585659892308012167@gauss>
2026-01-15 21:49 ` [Starlink] Re: Starlink and Iran Colin_Higbie
2026-01-15 23:15 ` Frantisek Borsik
2026-01-16 0:13 ` Ulrich Speidel
2026-01-16 1:29 ` David Lang
2026-01-16 22:55 ` Frantisek Borsik
2026-01-16 23:06 ` J Pan
[not found] ` <13187.1768590201@obiwan.sandelman.ca>
2026-01-16 23:30 ` Ulrich Speidel
2026-01-17 0:07 ` David Lang
2026-01-17 21:56 ` Ulrich Speidel
2026-01-19 20:39 ` David Lang
2026-01-28 3:09 ` Ulrich Speidel
2026-01-28 3:30 ` David Lang
2026-01-28 4:02 ` Mike Puchol
2026-01-28 9:05 ` Ulrich Speidel
2026-01-28 9:53 ` David Lang [this message]
2026-01-28 20:43 ` Ulrich Speidel
2026-01-28 20:55 ` David Lang
2026-01-17 18:32 ` Michael Richardson
2026-01-17 18:38 ` Inemesit Affia
2026-01-17 19:25 ` Michael Richardson
2026-01-17 22:12 ` Ulrich Speidel
[not found] <176849731431.1249.14387618908540773471@gauss>
2026-01-15 17:42 ` Colin_Higbie
2026-01-15 18:56 ` Jim Forster
2026-01-15 20:15 ` Ulrich Speidel
2026-01-15 20:27 ` Ulrich Speidel
2026-01-15 20:30 ` Hayden Simon
2026-01-15 21:06 ` Ulrich Speidel
2026-01-15 21:09 ` Hayden Simon
2026-01-15 21:20 ` Ulrich Speidel
2026-01-15 21:23 ` Hayden Simon
2026-01-15 14:50 David Fernández
2026-01-15 16:11 ` Oleg Kutkov
2026-01-15 17:13 ` J Pan
-- strict thread matches above, loose matches on Subject: below --
2026-01-15 9:51 [Starlink] " Ulrich Speidel
2026-01-15 10:06 ` [Starlink] " Inemesit Affia
2026-01-15 10:30 ` Ulrich Speidel
2026-01-15 10:44 ` Inemesit Affia
2026-01-15 11:16 ` Ulrich Speidel
2026-01-15 10:32 ` Inemesit Affia
2026-01-15 10:51 ` Ulrich Speidel
2026-01-15 11:17 ` David Lang
2026-01-15 11:59 ` Sauli Kiviranta
2026-01-15 14:08 ` David Lang
2026-01-15 15:29 ` Sauli Kiviranta
[not found] ` <3af2ac06-e098-4c79-869d-9c389959ca07@gmail.com>
[not found] ` <q9304244-661o-3qsr-o6rp-9q1nqq09r419@ynat.uz>
[not found] ` <4ba64a41-bbbf-4fb5-adb0-c77c15e4ca0f@gmail.com>
2026-01-15 16:20 ` Inemesit Affia
2026-01-15 20:12 ` Ulrich Speidel
2026-01-15 17:10 ` J Pan
2026-01-15 20:07 ` Ulrich Speidel
2026-01-15 21:47 ` Oleg Kutkov
2026-01-16 4:18 ` Ulrich Speidel
2026-01-16 8:12 ` Frantisek Borsik
2026-01-16 8:24 ` Inemesit Affia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=89q404n0-7205-86o5-p825-o6o140619o6n@ynat.uz \
--to=david@lang.hm \
--cc=mcr@sandelman.ca \
--cc=mike@starlink.sx \
--cc=starlink@lists.bufferbloat.net \
--cc=u.speidel@auckland.ac.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox