From: David Lang <david@lang.hm>
To: Ulrich Speidel <u.speidel@auckland.ac.nz>
Cc: David Lang <david@lang.hm>, Michael Richardson <mcr@sandelman.ca>,
starlink@lists.bufferbloat.net
Subject: [Starlink] Re: Starlink and Iran
Date: Tue, 27 Jan 2026 20:30:34 -0700 (MST) [thread overview]
Message-ID: <o7o2spor-3o39-o594-r163-q0n5p2o8or25@ynat.uz> (raw)
In-Reply-To: <3be747c6-793e-4b44-b1e1-52ee7ba9b6b0@auckland.ac.nz>
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
next prev parent reply other threads:[~2026-01-28 3:30 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 [this message]
2026-01-28 4:02 ` Mike Puchol
2026-01-28 9:05 ` Ulrich Speidel
2026-01-28 9:53 ` David Lang
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=o7o2spor-3o39-o594-r163-q0n5p2o8or25@ynat.uz \
--to=david@lang.hm \
--cc=mcr@sandelman.ca \
--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