From: Ulrich Speidel <u.speidel@auckland.ac.nz>
To: Michael Richardson <mcr@sandelman.ca>, starlink@lists.bufferbloat.net
Subject: [Starlink] Re: Starlink and Iran
Date: Sun, 18 Jan 2026 11:12:17 +1300 [thread overview]
Message-ID: <f5d2b048-5388-450c-990f-b261983ccdb4@auckland.ac.nz> (raw)
In-Reply-To: <1445.1768674722@obiwan.sandelman.ca>
On 18/01/2026 7:32 am, Michael Richardson wrote:
> --------
>
> Ulrich Speidel <u.speidel@auckland.ac.nz> wrote:
> >> 1. Who checks/enforces this ITU limit?
>
> > The licensing authorities in the respective countries (i.e., the FCC in the
> > US - and they're held to account by their competitors, of which SpaceX has a
> > few in the US). At an international level, if one country were to
> > ignore
>
> Yes, but dieselgate. Obey, except when it is important not to.
Except that if you ignore this in orbit, you'd find that you have to put
up with interference from others' systems, too, who will now see your
breach of the rules as license to do this for you.
>
> >> 2. Could the physically satellites go higher over some territory? How much higher?
> >> I assume it's software controlled.
>
> > A satellite has three types of energy that determine its orbital motion:
> > Potential energy from orbital height, kinetic energy from moving, and
> > energy
>
> Sorry, you mis-understood, or I mis-typed, I now understand.
> I meant, go to a higher-power. Not a higher orbit :-)
I'd misunderstood you there indeed. The answer is "no, but ...". I
gather that the transmitters on Starlink satellites are all DSP based,
and given that they were probably designed for the original limits that
SpaceX had promised to adhere to, I'd say it's likely that this won't be
possible with most of the current fleet - their maximum EIRP is well
documented and you don't design a transmitter to be more powerful than
it needs to be, especially when it has to go into space, as this just
adds weight (and probably reduces demisability). So that would have to
be done via redesign and orbit re-stocking rather than just flicking a
switch. But: With DSP, you get to choose which part of the spectrum you
put your EIRP into ... and if you shrink that (sub-)band, then yes you
presumably could project higher power flux density even from the
existing birds - at a bit of a cost in terms of capacity. But given the
relatively low number of Dishys in Iran, that probably wouldn't be much
of an issue. But it would change what your Dishy needs to look for in
terms of beam signal structure, and that might be less trivial to handle.
Plus it doesn't do anything if the positioning is out by many many
miles, which seems to be the aim with the GPS spoofing / jamming attacks
in Iran.
> ----
>
> (Has anyone proposed eliptical orbits for LEOs or MEOs, such that they would
> be lower whenever they are over the service territory, and higher otherwise.
> I imagine it would be horribly complex to work out, given various
> precessions, and it's not clear to me why. I think because less drag when
> not low down...)
That's historically been done for polar sites, albeit in such a way that
the satellite would be high above the poles (to maximise time in view)
and low around the Equator. And that wasn't LEO. The biggest problem
with doing this in LEO space is that the satellite is fastest when it's
closest to Earth, and drag is proportional to the square of the speed,
so such an orbit would require a lot of fuel to maintain.
--
****************************************************************
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/
****************************************************************
next prev parent reply other threads:[~2026-01-17 22:12 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
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 [this message]
[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=f5d2b048-5388-450c-990f-b261983ccdb4@auckland.ac.nz \
--to=u.speidel@auckland.ac.nz \
--cc=mcr@sandelman.ca \
--cc=starlink@lists.bufferbloat.net \
/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