[Starlink] Re: Starlink and Iran

[Starlink] Re: Starlink and Iran

[Colin_Higbie]

Ulrich, thanks. That's a great description and you're right that I had not appreciated how much more directional these are today  (in fact, in the early military applications, before it was available in cell phones, the lack of directionality was important to protect our teams from being located, even as they were transmitting from close to an enemy location).

However, this creates a follow-up question: working as you describe, which I accept as correct, why the big concern from Jeff Bezos and others about the sky coverage of the Starlink LEO constellation making it tough for them? If the signal is as hyperdirectional as you've described (also saw your laser pointer example in response to Hayden Simon), I would think that means very low risk of significant interference between two nearby layers of satellites. Even with thousands zipping around the Earth, I would think the probability is quite low of any two of them being on the same line to a home dish. What kind of interference are Starlink's competitors complaining about? Is it that while it's tight beam, it's still not *that* tight, so if they're within a few miles of each other, that's enough to trigger interference?

Thanks,
Colin


-----Original Message-----
From: Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net>
Sent: Friday, 16 January 2026 9:27 am
To: starlink@lists.bufferbloat.net
Subject: [Starlink] Re: Starlink and Iran

On 16/01/2026 6:42 am, Colin_Higbie via Starlink wrote:
> Can't the traditional approach of just flooding the air with noise reduce the SNR to the point that most packets are indecipherable? I don't believe this requires a digital or technically advanced approach nor a focus on GPS or anything else so specific, just sufficient power and ability to broadcast fully across the same spectrum bands to drown out the valid signals. Starlink, like cellular technology, uses excellent methods to operate amidst a lot of noise and find its packets, but it's still not immune to noise.
>
> Iran is a large area, and probably the government lacks the ability to block the entire nation simultaneously, but I would think they could drown out the signal in specific geographic regions, effectively jamming the signal entirely or almost entirely in those areas.
>
> Perhaps some of the cellular or satcom experts here can expand on or correct me if I'm mistaken. My physics knowledge on this has not updated much since the original spread spectrum work decades ago.

The original spread spectrum work concerned much much lower frequencies (in the MHz rather than the GHz) and the physics that goes with lower frequencies (not just spread spectrum) is that at the time, jamming was mostly used against receivers with fairly omnidirectional antennas. 
Read: It doesn't really matter where you transmit your interfering signal from - the receiver will hear it. It also helps that the (free
space) path loss of RF signals is proportional to the square of the frequency, so low frequency means you can hit a receiver over a substantial distance with relatively little power.

Starlink is a different ballgame: It operates in Ku-band above 10 GHz. 
This means highly directional antennas - so you literally need to transmit into the receive beam from the beam's preferred direction to be able to jam at all. Plus having to invest more power to bridge the distance means that flooding just isn't an option here.

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

[Starlink] Re: Starlink and Iran

[Frantisek Borsik]

Shared with me by one of the silent members of the list. We are not sure
about the accuracy of it, but here you are:

https://www.nextbigfuture.com/2026/01/iran-jamming-of-starlink-and-ways-to-overcome-jamming.html

All the best,

Frank

Frantisek (Frank) Borsik


*In loving memory of Dave Täht: *1965-2025

https://libreqos.io/2025/04/01/in-loving-memory-of-dave/


https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik@gmail.com


On Thu, Jan 15, 2026 at 10:49 PM Colin_Higbie via Starlink <
starlink@lists.bufferbloat.net> wrote:

> Ulrich, thanks. That's a great description and you're right that I had not
> appreciated how much more directional these are today  (in fact, in the
> early military applications, before it was available in cell phones, the
> lack of directionality was important to protect our teams from being
> located, even as they were transmitting from close to an enemy location).
>
> However, this creates a follow-up question: working as you describe, which
> I accept as correct, why the big concern from Jeff Bezos and others about
> the sky coverage of the Starlink LEO constellation making it tough for
> them? If the signal is as hyperdirectional as you've described (also saw
> your laser pointer example in response to Hayden Simon), I would think that
> means very low risk of significant interference between two nearby layers
> of satellites. Even with thousands zipping around the Earth, I would think
> the probability is quite low of any two of them being on the same line to a
> home dish. What kind of interference are Starlink's competitors complaining
> about? Is it that while it's tight beam, it's still not *that* tight, so if
> they're within a few miles of each other, that's enough to trigger
> interference?
>
> Thanks,
> Colin
>
>
> -----Original Message-----
> From: Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net>
> Sent: Friday, 16 January 2026 9:27 am
> To: starlink@lists.bufferbloat.net
> Subject: [Starlink] Re: Starlink and Iran
>
> On 16/01/2026 6:42 am, Colin_Higbie via Starlink wrote:
> > Can't the traditional approach of just flooding the air with noise
> reduce the SNR to the point that most packets are indecipherable? I don't
> believe this requires a digital or technically advanced approach nor a
> focus on GPS or anything else so specific, just sufficient power and
> ability to broadcast fully across the same spectrum bands to drown out the
> valid signals. Starlink, like cellular technology, uses excellent methods
> to operate amidst a lot of noise and find its packets, but it's still not
> immune to noise.
> >
> > Iran is a large area, and probably the government lacks the ability to
> block the entire nation simultaneously, but I would think they could drown
> out the signal in specific geographic regions, effectively jamming the
> signal entirely or almost entirely in those areas.
> >
> > Perhaps some of the cellular or satcom experts here can expand on or
> correct me if I'm mistaken. My physics knowledge on this has not updated
> much since the original spread spectrum work decades ago.
>
> The original spread spectrum work concerned much much lower frequencies
> (in the MHz rather than the GHz) and the physics that goes with lower
> frequencies (not just spread spectrum) is that at the time, jamming was
> mostly used against receivers with fairly omnidirectional antennas.
> Read: It doesn't really matter where you transmit your interfering signal
> from - the receiver will hear it. It also helps that the (free
> space) path loss of RF signals is proportional to the square of the
> frequency, so low frequency means you can hit a receiver over a substantial
> distance with relatively little power.
>
> Starlink is a different ballgame: It operates in Ku-band above 10 GHz.
> This means highly directional antennas - so you literally need to transmit
> into the receive beam from the beam's preferred direction to be able to jam
> at all. Plus having to invest more power to bridge the distance means that
> flooding just isn't an option here.
>
> --
> ****************************************************************
> 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/
> ****************************************************************
>
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>

[Starlink] Re: Starlink and Iran

[Ulrich Speidel]

Hi Colin, great question!

The analogy between beams that come down from the satellites and a laser 
pointer / telescope combination as a replacement for the phased array 
antennas is of course conceptual only. Starlink user downlink beams are 
beam shaped and put a circular spot on the surface of Earth that 
essentially covers a hexagonal (or in rarer cases pentagonal) cell on 
the ground (H3 cell as per Uber H3 at resolution 5 o 6 - nod to Mike 
Puchol here for bringing this up some time ago). These are a few miles 
wide. Within that cell, SpaceX can use each available 
frequency-polarisation combination only once for a beam.

What does "available" mean? These are all in a 2000 MHz (2 GHz) wide 
band between 10.7 and 12.7 GHz (Ku down). For starters, SpaceX needs a 
license for whatever part of that band it wants to use in this location. 
Even if SpaceX has a license, it may not be able to use all of the 
frequency-polarisation combinations there, e.g., because there are 
Dishys in adjacent cells that also need service and  
frequency-polarisation combination in use in one cell can't be re-used 
in its neighbourhood (much like in a cellphone network). Now in a lot of 
communication situations you can make up for lack of frequency bandwidth 
by increasing power and transmitting more bits per symbol. Not so here. 
Why? Because there is a limit on the amount of power per square metre 
and MHz of bandwidth (EPFD) that systems such as Starlink may project 
onto the surface of the Earth. It's an ITU-imposed limit, so the FCC 
can't really do much about it. SpaceX are on public record for not being 
happy with it and with their v2's they're riding right up against that 
limit. This essentially limits capacity per cell in dependence of what 
the licensing environment and the cell's neighbourhood look like in 
terms of demand. It's one of the reasons why Starlink downlink rates 
differ from place to place.

Now the aforementioned Ku-band is also shared, and there aren't really 
any other usable bands. Go down in frequency and it gets crowded, you 
need bigger antennas and focussing and steering your beam becomes much 
harder. Go further up in frequency and rain fade becomes a serious issue 
- for which you'd need to compensate with bigger Dishys. So that Ku band 
is where everyone wants to be: OneWeb, SpaceX, Kuiper, and whoever else 
is currently building LEO networks. Now if Elon gets permission to put a 
beam on frequency f into your neighbourhood, then that's his patch on 
that frequency, and Jeff & Co. either need to find themselves a 
frequency that isn't taken there yet (and isn't in use by Elon in the 
neighbourhood either), or they need to persuade the FCC to take it off 
Elon.

The other issue is orbits: Starlink now occupies an increasing amount of 
space real estate in the LEO Goldilocks zone. Go higher and you pay in 
terms of latency, and it also becomes harder to direct your beams into 
small spots on the ground. Plus you need more transmitter power or 
antenna gain to get to the EPFD limit. Go lower and you'll pay in terms 
of satellite lifetime - not ideal unless you have rapid launch 
capability. Try and snuggle up with Starlink at the same altitude and 
someone will argue that this increases the risk of collisions and hence 
Kessler syndrome.

So that's why Jeff Bezos and others are worried.

On 16/01/2026 10:49 am, Colin_Higbie via Starlink wrote:
> Ulrich, thanks. That's a great description and you're right that I had not appreciated how much more directional these are today  (in fact, in the early military applications, before it was available in cell phones, the lack of directionality was important to protect our teams from being located, even as they were transmitting from close to an enemy location).
>
> However, this creates a follow-up question: working as you describe, which I accept as correct, why the big concern from Jeff Bezos and others about the sky coverage of the Starlink LEO constellation making it tough for them? If the signal is as hyperdirectional as you've described (also saw your laser pointer example in response to Hayden Simon), I would think that means very low risk of significant interference between two nearby layers of satellites. Even with thousands zipping around the Earth, I would think the probability is quite low of any two of them being on the same line to a home dish. What kind of interference are Starlink's competitors complaining about? Is it that while it's tight beam, it's still not *that* tight, so if they're within a few miles of each other, that's enough to trigger interference?
>
> Thanks,
> Colin
>
>
> -----Original Message-----
> From: Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net>
> Sent: Friday, 16 January 2026 9:27 am
> To: starlink@lists.bufferbloat.net
> Subject: [Starlink] Re: Starlink and Iran
>
> On 16/01/2026 6:42 am, Colin_Higbie via Starlink wrote:
>> Can't the traditional approach of just flooding the air with noise reduce the SNR to the point that most packets are indecipherable? I don't believe this requires a digital or technically advanced approach nor a focus on GPS or anything else so specific, just sufficient power and ability to broadcast fully across the same spectrum bands to drown out the valid signals. Starlink, like cellular technology, uses excellent methods to operate amidst a lot of noise and find its packets, but it's still not immune to noise.
>>
>> Iran is a large area, and probably the government lacks the ability to block the entire nation simultaneously, but I would think they could drown out the signal in specific geographic regions, effectively jamming the signal entirely or almost entirely in those areas.
>>
>> Perhaps some of the cellular or satcom experts here can expand on or correct me if I'm mistaken. My physics knowledge on this has not updated much since the original spread spectrum work decades ago.
> The original spread spectrum work concerned much much lower frequencies (in the MHz rather than the GHz) and the physics that goes with lower frequencies (not just spread spectrum) is that at the time, jamming was mostly used against receivers with fairly omnidirectional antennas.
> Read: It doesn't really matter where you transmit your interfering signal from - the receiver will hear it. It also helps that the (free
> space) path loss of RF signals is proportional to the square of the frequency, so low frequency means you can hit a receiver over a substantial distance with relatively little power.
>
> Starlink is a different ballgame: It operates in Ku-band above 10 GHz.
> This means highly directional antennas - so you literally need to transmit into the receive beam from the beam's preferred direction to be able to jam at all. Plus having to invest more power to bridge the distance means that flooding just isn't an option here.
>
> --
> ****************************************************************
> 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/
> ****************************************************************
>
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

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

[Starlink] Re: Starlink and Iran

[David Lang]

Ulrich Speidel wrote:

> The other issue is orbits: Starlink now occupies an increasing amount of 
> space real estate in the LEO Goldilocks zone. Go higher and you pay in terms 
> of latency, and it also becomes harder to direct your beams into small spots 
> on the ground. Plus you need more transmitter power or antenna gain to get to 
> the EPFD limit. Go lower and you'll pay in terms of satellite lifetime - not 
> ideal unless you have rapid launch capability.

Starlink recently announce it was lowering the altitude of about half their 
satellites.

David Lang

[Starlink] Re: Starlink and Iran

[Frantisek Borsik]

"We've received some reports indicating that the Iranian regime is using
handheld/vehicular scanners to detect WiFi signals (especially networks
with default or strong names) to locate Starlink sources.

Why? Because WiFi is FAR easier to detect than satellite signals.
Starlink's uplink/downlink is highly directional and hard to pinpoint from
ground level, but your router's WiFi broadcasts in all directions from your
home.

If your friends are inside Iran using Starlink: tell them to enable Bypass
Mode to disable the built-in WiFi, or at minimum hide their SSID and change
the network name."

https://x.com/NarimanGharib/status/2012177548247969826?s=20

All the best,

Frank

Frantisek (Frank) Borsik


*In loving memory of Dave Täht: *1965-2025

https://libreqos.io/2025/04/01/in-loving-memory-of-dave/


https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik@gmail.com


On Fri, Jan 16, 2026 at 2:29 AM David Lang via Starlink <
starlink@lists.bufferbloat.net> wrote:

> Ulrich Speidel wrote:
>
> > The other issue is orbits: Starlink now occupies an increasing amount of
> > space real estate in the LEO Goldilocks zone. Go higher and you pay in
> terms
> > of latency, and it also becomes harder to direct your beams into small
> spots
> > on the ground. Plus you need more transmitter power or antenna gain to
> get to
> > the EPFD limit. Go lower and you'll pay in terms of satellite lifetime -
> not
> > ideal unless you have rapid launch capability.
>
> Starlink recently announce it was lowering the altitude of about half
> their
> satellites.
>
> David Lang
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>

[Starlink] Re: Starlink and Iran

[J Pan]

"Amendment to my earlier warning about IR regime scanning for Starlink
WiFi signals:Hiding SSID or using Bypass Mode is a helpful step, but
NOT bulletproof—scanners can still detect the active WiFi radio.The
safest option: TURN OFF WiFi broadcast entirely on the Starlink
router. Use only wired Ethernet connections."? for life-critical
things, better read, think and discuss (3), do and improve (2), and
write (1). why cautious about twitter/x/alike
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan


On Fri, Jan 16, 2026 at 2:52 PM Frantisek Borsik via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> "We've received some reports indicating that the Iranian regime is using
> handheld/vehicular scanners to detect WiFi signals (especially networks
> with default or strong names) to locate Starlink sources.
>
> Why? Because WiFi is FAR easier to detect than satellite signals.
> Starlink's uplink/downlink is highly directional and hard to pinpoint from
> ground level, but your router's WiFi broadcasts in all directions from your
> home.
>
> If your friends are inside Iran using Starlink: tell them to enable Bypass
> Mode to disable the built-in WiFi, or at minimum hide their SSID and change
> the network name."
>
> https://x.com/NarimanGharib/status/2012177548247969826?s=20
>
> All the best,
>
> Frank
>
> Frantisek (Frank) Borsik
>
>
> *In loving memory of Dave Täht: *1965-2025
>
> https://libreqos.io/2025/04/01/in-loving-memory-of-dave/
>
>
> https://www.linkedin.com/in/frantisekborsik
>
> Signal, Telegram, WhatsApp: +421919416714
>
> iMessage, mobile: +420775230885
>
> Skype: casioa5302ca
>
> frantisek.borsik@gmail.com
>
>
> On Fri, Jan 16, 2026 at 2:29 AM David Lang via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
> > Ulrich Speidel wrote:
> >
> > > The other issue is orbits: Starlink now occupies an increasing amount of
> > > space real estate in the LEO Goldilocks zone. Go higher and you pay in
> > terms
> > > of latency, and it also becomes harder to direct your beams into small
> > spots
> > > on the ground. Plus you need more transmitter power or antenna gain to
> > get to
> > > the EPFD limit. Go lower and you'll pay in terms of satellite lifetime -
> > not
> > > ideal unless you have rapid launch capability.
> >
> > Starlink recently announce it was lowering the altitude of about half
> > their
> > satellites.
> >
> > David Lang
> > _______________________________________________
> > Starlink mailing list -- starlink@lists.bufferbloat.net
> > To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
> >
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

[Starlink] Re: Starlink and Iran

[Ulrich Speidel]

On 17/01/2026 8:03 am, Michael Richardson wrote:
> Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net> wrote:
>      > here. Why? Because there is a limit on the amount of power per square metre
>      > and MHz of bandwidth (EPFD) that systems such as Starlink may project onto
>      > the surface of the Earth. It's an ITU-imposed limit, so the FCC can't really
>      > do much about it. SpaceX are on public record for not being happy with it and
>      > with their v2's they're riding right up against that limit.
>
> 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 this, so would everyone else, which would make 
space-to-ground comms in these bands pretty unworkable pretty quickly as 
there'd be a lot of "my output power is bigger than yours" happening. 
One of the main reasons for having this limit is to ensure GEO sats can 
get their signals through. Whether the current level that the limit is 
set at and the way it's computed is appropriate is another question, and 
SpaceX have certainly tried to litigate that before the FCC.
> 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 stored in its thruster fuel. If you don't use the thrusters, the 
normal course of events is that over time, you convert potential energy 
into kinetic energy and eventually lose height to end up in the upper 
reaches of the atmosphere where you burn up. To increase or even just 
maintain orbital height, you need to convert fuel energy and kinetic 
energy into potential energy. Just converting kinetic energy into 
potential energy isn't enough - it leaves your satellite with too little 
kinetic energy to keep orbiting. So yes the satellites can in principle 
go a bit higher but at the expense of fuel and therefore lifespan.

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

[Starlink] Re: Starlink and Iran

[David Lang]

Ulrich Speidel wrote:

> On 17/01/2026 8:03 am, Michael Richardson wrote:

>> Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net> wrote:

>> here. Why? Because there is a limit on the amount of power per square metre 
>> and MHz of bandwidth (EPFD) that systems such as Starlink may project onto 
>> the surface of the Earth. It's an ITU-imposed limit, so the FCC can't really 
>> do much about it. SpaceX are on public record for not being happy with it and 
>> with their v2's they're riding right up against that limit.

>> 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 
> this, so would everyone else, which would make space-to-ground comms in these 
> bands pretty unworkable pretty quickly as there'd be a lot of "my output 
> power is bigger than yours" happening. One of the main reasons for having 
> this limit is to ensure GEO sats can get their signals through. Whether the 
> current level that the limit is set at and the way it's computed is 
> appropriate is another question, and SpaceX have certainly tried to litigate 
> that before the FCC.

have you looked at what the latest changes allow?

>> 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 
> stored in its thruster fuel.

I think he's talking about the radio energy at the receiver, not satellite 
energy.

David Lang

[Starlink] Re: Starlink and Iran

[Ulrich Speidel]

On 17/01/2026 1:07 pm, David Lang wrote:
>
>> 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 this, so would everyone else, which would make 
>> space-to-ground comms in these bands pretty unworkable pretty quickly 
>> as there'd be a lot of "my output power is bigger than yours" 
>> happening. One of the main reasons for having this limit is to ensure 
>> GEO sats can get their signals through. Whether the current level 
>> that the limit is set at and the way it's computed is appropriate is 
>> another question, and SpaceX have certainly tried to litigate that 
>> before the FCC.
>
> have you looked at what the latest changes allow?
No - if anyone has a pointer to what the official source for the latest 
SpaceX-FCC licensing interactions is ... I'd been hoping to figure that 
out but haven't yet.
>
>>> 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 stored in its thruster fuel.
>
> I think he's talking about the radio energy at the receiver, not 
> satellite energy.
Will respond to Michael's response on this shortly.

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

[Starlink] Re: Starlink and Iran

[David Lang]

Ulrich Speidel wrote:

> David Lang wrote:
>> have you looked at what the latest changes allow?

> No - if anyone has a pointer to what the official source for the latest 
> SpaceX-FCC licensing interactions is ... I'd been hoping to figure that out 
> but haven't yet.

not much info here, but hopefully a start 
https://www.fcc.gov/document/fcc-approves-next-gen-satellite-constellation

A few days before this, spacex announced it was lowering the orbit for ~4000 of 
it's satellites by ~70km
https://www.space.com/space-exploration/satellites/spacex-lowering-orbits-of-4-400-starlink-satellites-for-safetys-sake

David Lang

[Starlink] Re: Starlink and Iran

[Ulrich Speidel]

On 20/01/2026 9:39 am, David Lang wrote:
> Ulrich Speidel wrote:
>
>> David Lang wrote:
>>> have you looked at what the latest changes allow?
>
>> No - if anyone has a pointer to what the official source for the 
>> latest SpaceX-FCC licensing interactions is ... I'd been hoping to 
>> figure that out but haven't yet.
>
> not much info here, but hopefully a start 
> https://www.fcc.gov/document/fcc-approves-next-gen-satellite-constellation
>
> A few days before this, spacex announced it was lowering the orbit for 
> ~4000 of it's satellites by ~70km
> https://www.space.com/space-exploration/satellites/spacex-lowering-orbits-of-4-400-starlink-satellites-for-safetys-sake 
>

OK, this took a moment. There are a few references to waivers of EPFD 
limits in the document but these needed a little research. The crux is 
in point 4 of the grant document, which makes reference to sections 
25.146(a)(2) and (c) of the FCC rules. Now 25.146(a)(2) references 
Article 22 and Resolution 76 of the ITU radio regulations. These impose 
EPFD limits on interference to geostationary systems from the aggregate 
operation of non-geostationary systems.

While these may or may not require SpaceX to stick to lower transmit 
power at times than the limits in Article 21 (which haven't been waived 
for all I can tell), it's the limits imposed by Article 21 that continue 
to put a lid on things.

So this doesn't look like good news in terms of being able to throttle up.

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.

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.
  * 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?

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

[Starlink] Re: Starlink and Iran

[David Lang]

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] Re: Starlink and Iran

[Mike Puchol]

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

[Starlink] Re: Starlink and Iran

[Ulrich Speidel]

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

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

[Starlink] Re: Starlink and Iran

[David Lang]

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
>
>

[Starlink] Re: Starlink and Iran

[Ulrich Speidel]

Again, not that straightforward.

These beams have to come from somewhere, and there has to be - from the 
ground perspective - some angular separation between them, lest adjacent 
beams both end up in the main lobe of the same receiver on the ground. 
So there's only so much potential here - and 8 beams might already be 
pushing it in a dynamic environment like LEO. Remember: You have to 
maintain that angular separation until at least the next handover (and 
you don't want to have these too often as they mean packets being sent 
pre-handover into queues heading for the pre-handover satellite -> 
packet loss if these queues don't clear before the handover).

Phased arrays (unlike real dishes) also have non-insignificant side 
lobes, and an unwanted beam getting into one of those raises the noise 
floor.

User density isn't just a matter of population density but also of fibre 
and mobile penetration on the ground. In places like NZ, where fibre 
penetration in cities and towns is high, user density is highest in 
their outer periphery (where lifestyle block meets IT manager just 
outside fibre coverage). In other places, where there hasn't ever been a 
concerted push to fibre up cities, you find it's the townsfolk who buy 
Starlink's shelves bare. The US are probably more in that category.

Going over the limits in the US would be a nice experiment I think. If 
it works there, I'm sure the likes of Brazil and the Philippines would 
be watching closely.

On 28/01/2026 10:53 pm, David Lang wrote:
> 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
>>
>>
-- 
****************************************************************
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/
****************************************************************

[Starlink] Re: Starlink and Iran

[David Lang]

Ulrich Speidel wrote:

> Again, not that straightforward.
>
> These beams have to come from somewhere, and there has to be - from the 
> ground perspective - some angular separation between them, lest adjacent 
> beams both end up in the main lobe of the same receiver on the ground. So 
> there's only so much potential here - and 8 beams might already be pushing it 
> in a dynamic environment like LEO. Remember: You have to maintain that 
> angular separation until at least the next handover (and you don't want to 
> have these too often as they mean packets being sent pre-handover into queues 
> heading for the pre-handover satellite -> packet loss if these queues don't 
> clear before the handover).
>
> Phased arrays (unlike real dishes) also have non-insignificant side lobes, 
> and an unwanted beam getting into one of those raises the noise floor.

does anyone know what the various starlink dishe patterns look like?

everything you say is correct, but with ~10x the number of satellites needed for 
full coverage, and the satellites supporting multiple beams each (with newer 
satellites supporting more beams), it would seem reasonable to expect that there 
are enough in the right place at the right time.

personally, I would opt for more handovers if it means being able to support 
more users in an area. I normally do not notice handovers, so am not that 
worried about it.

> User density isn't just a matter of population density but also of fibre and 
> mobile penetration on the ground. In places like NZ, where fibre penetration 
> in cities and towns is high, user density is highest in their outer periphery 
> (where lifestyle block meets IT manager just outside fibre coverage). In 
> other places, where there hasn't ever been a concerted push to fibre up 
> cities, you find it's the townsfolk who buy Starlink's shelves bare. The US 
> are probably more in that category.

exactly my thoughts.

> Going over the limits in the US would be a nice experiment I think. If it 
> works there, I'm sure the likes of Brazil and the Philippines would be 
> watching closely.

exactly what I think is happening, and why I'm not as worried about 
international agreements as you are.

David Lang

[Starlink] Re: Starlink and Iran

[Michael Richardson]

--------

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.

    >> 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 :-)

----

(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...)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

[Starlink] Re: Starlink and Iran

[Inemesit Affia]

By different orbits you mean like Molniya? The Russians use that

On Sat, Jan 17, 2026, 7:32 PM Michael Richardson via Starlink <
starlink@lists.bufferbloat.net> 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.
>
>     >> 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 :-)
>
> ----
>
> (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...)
>
>
>
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT
> architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
> rails    [
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>

[Starlink] Re: Starlink and Iran

[Michael Richardson]

--------

Inemesit Affia <inemesitaffia@gmail.com> wrote:
         > By different orbits you mean like Molniya? The Russians use that

Yes, thanks for the reference.
I knew that this had been done before.

From what I understand, the useable portion of the orbit is when the
satellite is at it's furthest from the earth.  That's when it spends the most
amount of time, going the slowest.

But, I think I'm asking about the opposite: the target area would be when
it's lowest.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

[Starlink] Re: Starlink and Iran

[Ulrich Speidel]

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

[Starlink] Re: Starlink and Iran

[Colin_Higbie]

Can't the traditional approach of just flooding the air with noise reduce the SNR to the point that most packets are indecipherable? I don't believe this requires a digital or technically advanced approach nor a focus on GPS or anything else so specific, just sufficient power and ability to broadcast fully across the same spectrum bands to drown out the valid signals. Starlink, like cellular technology, uses excellent methods to operate amidst a lot of noise and find its packets, but it's still not immune to noise.

Iran is a large area, and probably the government lacks the ability to block the entire nation simultaneously, but I would think they could drown out the signal in specific geographic regions, effectively jamming the signal entirely or almost entirely in those areas.

Perhaps some of the cellular or satcom experts here can expand on or correct me if I'm mistaken. My physics knowledge on this has not updated much since the original spread spectrum work decades ago. 

Cheers,
Colin

[Starlink] Re: Starlink and Iran

[Jim Forster]

Another detection used in other places is to look for emissions that the terminals might make.  Back in the days of analog TV, which are nominally receivers,, I understand  UK OFCOM would check for people that had TV’s and were not paying their license fee, by listening for the characteristic IF (intermediate frequency) that the heterodyne? based receivers emitted. 

I’ve no idea if approach can be used now,  Anyone?

  — Jim


> On Jan 15, 2026, at 9:42 AM, Colin_Higbie via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> Can't the traditional approach of just flooding the air with noise reduce the SNR to the point that most packets are indecipherable? I don't believe this requires a digital or technically advanced approach nor a focus on GPS or anything else so specific, just sufficient power and ability to broadcast fully across the same spectrum bands to drown out the valid signals. Starlink, like cellular technology, uses excellent methods to operate amidst a lot of noise and find its packets, but it's still not immune to noise.
> 
> Iran is a large area, and probably the government lacks the ability to block the entire nation simultaneously, but I would think they could drown out the signal in specific geographic regions, effectively jamming the signal entirely or almost entirely in those areas.
> 
> Perhaps some of the cellular or satcom experts here can expand on or correct me if I'm mistaken. My physics knowledge on this has not updated much since the original spread spectrum work decades ago. 

[Starlink] Re: Starlink and Iran

[Ulrich Speidel]

Not really an option anymore ... these spurious emissions are pretty 
much history now.

On 16/01/2026 7:56 am, Jim Forster via Starlink wrote:
> Another detection used in other places is to look for emissions that the terminals might make.  Back in the days of analog TV, which are nominally receivers,, I understand  UK OFCOM would check for people that had TV’s and were not paying their license fee, by listening for the characteristic IF (intermediate frequency) that the heterodyne? based receivers emitted.
>
> I’ve no idea if approach can be used now,  Anyone?
>
>    — Jim
>
-- 
****************************************************************
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/
****************************************************************

[Starlink] Re: Starlink and Iran

[Ulrich Speidel]

On 16/01/2026 6:42 am, Colin_Higbie via Starlink wrote:
> Can't the traditional approach of just flooding the air with noise reduce the SNR to the point that most packets are indecipherable? I don't believe this requires a digital or technically advanced approach nor a focus on GPS or anything else so specific, just sufficient power and ability to broadcast fully across the same spectrum bands to drown out the valid signals. Starlink, like cellular technology, uses excellent methods to operate amidst a lot of noise and find its packets, but it's still not immune to noise.
>
> Iran is a large area, and probably the government lacks the ability to block the entire nation simultaneously, but I would think they could drown out the signal in specific geographic regions, effectively jamming the signal entirely or almost entirely in those areas.
>
> Perhaps some of the cellular or satcom experts here can expand on or correct me if I'm mistaken. My physics knowledge on this has not updated much since the original spread spectrum work decades ago.

The original spread spectrum work concerned much much lower frequencies 
(in the MHz rather than the GHz) and the physics that goes with lower 
frequencies (not just spread spectrum) is that at the time, jamming was 
mostly used against receivers with fairly omnidirectional antennas. 
Read: It doesn't really matter where you transmit your interfering 
signal from - the receiver will hear it. It also helps that the (free 
space) path loss of RF signals is proportional to the square of the 
frequency, so low frequency means you can hit a receiver over a 
substantial distance with relatively little power.

Starlink is a different ballgame: It operates in Ku-band above 10 GHz. 
This means highly directional antennas - so you literally need to 
transmit into the receive beam from the beam's preferred direction to be 
able to jam at all. Plus having to invest more power to bridge the 
distance means that flooding just isn't an option here.

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

[Starlink] Re: Starlink and Iran

[Hayden Simon]

That leaves the most likely alternative as the action occuring from reasonable altitude. Be that in orbit, weather balloon(s)....drones.


HAYDEN SIMON
UBER GROUP LIMITED
MANAGING DIRECTOR
E: h@uber.nz
M: 021 0707 014
W: www.uber.nz
53 PORT ROAD | PO BOX 5083 | WHANGAREI | NEW ZEALAND
-----Original Message-----
From: Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net> 
Sent: Friday, 16 January 2026 9:27 am
To: starlink@lists.bufferbloat.net
Subject: [Starlink] Re: Starlink and Iran

On 16/01/2026 6:42 am, Colin_Higbie via Starlink wrote:
> Can't the traditional approach of just flooding the air with noise reduce the SNR to the point that most packets are indecipherable? I don't believe this requires a digital or technically advanced approach nor a focus on GPS or anything else so specific, just sufficient power and ability to broadcast fully across the same spectrum bands to drown out the valid signals. Starlink, like cellular technology, uses excellent methods to operate amidst a lot of noise and find its packets, but it's still not immune to noise.
>
> Iran is a large area, and probably the government lacks the ability to block the entire nation simultaneously, but I would think they could drown out the signal in specific geographic regions, effectively jamming the signal entirely or almost entirely in those areas.
>
> Perhaps some of the cellular or satcom experts here can expand on or correct me if I'm mistaken. My physics knowledge on this has not updated much since the original spread spectrum work decades ago.

The original spread spectrum work concerned much much lower frequencies (in the MHz rather than the GHz) and the physics that goes with lower frequencies (not just spread spectrum) is that at the time, jamming was mostly used against receivers with fairly omnidirectional antennas. 
Read: It doesn't really matter where you transmit your interfering signal from - the receiver will hear it. It also helps that the (free
space) path loss of RF signals is proportional to the square of the frequency, so low frequency means you can hit a receiver over a substantial distance with relatively little power.

Starlink is a different ballgame: It operates in Ku-band above 10 GHz. 
This means highly directional antennas - so you literally need to transmit into the receive beam from the beam's preferred direction to be able to jam at all. Plus having to invest more power to bridge the distance means that flooding just isn't an option here.

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



_______________________________________________
Starlink mailing list -- starlink@lists.bufferbloat.net To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

[Starlink] Re: Starlink and Iran

[Ulrich Speidel]

On 16/01/2026 9:30 am, Hayden Simon wrote:
> That leaves the most likely alternative as the action occuring from reasonable altitude. Be that in orbit, weather balloon(s)....drones.
>
Not really. Think of a Starlink satellite's beam as a laser pointer 
pointing at Dishys on the ground that look at the satellite with a good 
old fashioned telescope (which is what the phased array effectively 
does). And vice versa (laser pointer at the Dishy, telescope at the 
satellite). To disrupt that signal, you have to get yourself in front of 
the telescope with your laser pointer so your interfering signal can 
even be seen. Getting in front of the telescopes on the ground is 
mission impossible because there are a few 10000 of them. Moreover, they 
suddenly switch direction to point at another satellite typically every 
15 to 75 s (which shorter intervals dominating).

Getting in front of the telescopes on the satellites is somewhat easier 
as there are fewer of them and - with a drone - you'd be further away 
and they'd already be pointing in your general direction if you're close 
to the Dishy you're trying to interfere with. But even so, you'd need 
one laser pointer per visible and usable satellite - in each cell you're 
wanting to take Starlink out on. Moreover, you wouldn't know whether the 
satellite is currently receiving from that cell on a red, blue, or green 
light frequency - so you'd have to pump power into all of them. Not trivial.

GPS interference is much easier.

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

[Starlink] Re: Starlink and Iran

[Hayden Simon]

Sorry, I was envisaging being above the terminals - above the leo birds (so, in orbit realistically) and then blasting the target area - wide band, high power, just noise, effectively drowning out the starlink birds from the dishy perspective.


HAYDEN SIMON
UBER GROUP LIMITED
MANAGING DIRECTOR
E: h@uber.nz
M: 021 0707 014
W: www.uber.nz
53 PORT ROAD | PO BOX 5083 | WHANGAREI | NEW ZEALAND
-----Original Message-----
From: Ulrich Speidel <u.speidel@auckland.ac.nz> 
Sent: Friday, 16 January 2026 10:07 am
To: Hayden Simon <h@uber.nz>; starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Re: Starlink and Iran

On 16/01/2026 9:30 am, Hayden Simon wrote:
> That leaves the most likely alternative as the action occuring from reasonable altitude. Be that in orbit, weather balloon(s)....drones.
>
Not really. Think of a Starlink satellite's beam as a laser pointer pointing at Dishys on the ground that look at the satellite with a good old fashioned telescope (which is what the phased array effectively does). And vice versa (laser pointer at the Dishy, telescope at the satellite). To disrupt that signal, you have to get yourself in front of the telescope with your laser pointer so your interfering signal can even be seen. Getting in front of the telescopes on the ground is mission impossible because there are a few 10000 of them. Moreover, they suddenly switch direction to point at another satellite typically every
15 to 75 s (which shorter intervals dominating).

Getting in front of the telescopes on the satellites is somewhat easier as there are fewer of them and - with a drone - you'd be further away and they'd already be pointing in your general direction if you're close to the Dishy you're trying to interfere with. But even so, you'd need one laser pointer per visible and usable satellite - in each cell you're wanting to take Starlink out on. Moreover, you wouldn't know whether the satellite is currently receiving from that cell on a red, blue, or green light frequency - so you'd have to pump power into all of them. Not trivial.

GPS interference is much easier.

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

[Starlink] Re: Starlink and Iran

[Ulrich Speidel]

The only way to be above the target area on a more or less permanent 
basis would be to be in geostationary orbit - and that's very far away, 
hard to get to for a country like Iran (getting into low earth orbit is 
easy, getting into geostationary orbit is a bit harder rocket-wise). 
 From up there, you'd need to project enough power to overcome a path 
loss that's about 300 to 4000 times worse than what a LEO bird has to 
contend with, into a much wider band, and over a much larger area. That 
takes an awful lot of power & antenna gain to do.

The other way round, it's more of an issue: Starlink transmissions, when 
hitting the high gain antenna of a geostationary receiver on the ground 
that's close to your Dishy, can drown out the GEO sat. That's why 
there's an ITU requirement to reduce or cease transmissions if you're a 
non-GEO sat and you're on the line between your intended receiver and 
the geostationary orbit.

On 16/01/2026 10:09 am, Hayden Simon wrote:
> Sorry, I was envisaging being above the terminals - above the leo birds (so, in orbit realistically) and then blasting the target area - wide band, high power, just noise, effectively drowning out the starlink birds from the dishy perspective.
>
>
> HAYDEN SIMON
> UBER GROUP LIMITED
> MANAGING DIRECTOR
> E: h@uber.nz
> M: 021 0707 014
> W: www.uber.nz
> 53 PORT ROAD | PO BOX 5083 | WHANGAREI | NEW ZEALAND
> -----Original Message-----
> From: Ulrich Speidel <u.speidel@auckland.ac.nz>
> Sent: Friday, 16 January 2026 10:07 am
> To: Hayden Simon <h@uber.nz>; starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] Re: Starlink and Iran
>
> On 16/01/2026 9:30 am, Hayden Simon wrote:
>> That leaves the most likely alternative as the action occuring from reasonable altitude. Be that in orbit, weather balloon(s)....drones.
>>
> Not really. Think of a Starlink satellite's beam as a laser pointer pointing at Dishys on the ground that look at the satellite with a good old fashioned telescope (which is what the phased array effectively does). And vice versa (laser pointer at the Dishy, telescope at the satellite). To disrupt that signal, you have to get yourself in front of the telescope with your laser pointer so your interfering signal can even be seen. Getting in front of the telescopes on the ground is mission impossible because there are a few 10000 of them. Moreover, they suddenly switch direction to point at another satellite typically every
> 15 to 75 s (which shorter intervals dominating).
>
> Getting in front of the telescopes on the satellites is somewhat easier as there are fewer of them and - with a drone - you'd be further away and they'd already be pointing in your general direction if you're close to the Dishy you're trying to interfere with. But even so, you'd need one laser pointer per visible and usable satellite - in each cell you're wanting to take Starlink out on. Moreover, you wouldn't know whether the satellite is currently receiving from that cell on a red, blue, or green light frequency - so you'd have to pump power into all of them. Not trivial.
>
> GPS interference is much easier.
>
> --
> ****************************************************************
> 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/
> ****************************************************************
>
>
>
-- 
****************************************************************
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/
****************************************************************

[Starlink] Re: Starlink and Iran

[Hayden Simon]

Ah yep, that makes sense 😊

Will be interesting to learn what they've actually done (sorry If ive missed that in this chain), to cause such trouble.


HAYDEN SIMON
UBER GROUP LIMITED
MANAGING DIRECTOR
E: h@uber.nz
M: 021 0707 014
W: www.uber.nz
53 PORT ROAD | PO BOX 5083 | WHANGAREI | NEW ZEALAND
-----Original Message-----
From: Ulrich Speidel <u.speidel@auckland.ac.nz> 
Sent: Friday, 16 January 2026 10:21 am
To: Hayden Simon <h@uber.nz>; starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Re: Starlink and Iran

The only way to be above the target area on a more or less permanent basis would be to be in geostationary orbit - and that's very far away, hard to get to for a country like Iran (getting into low earth orbit is easy, getting into geostationary orbit is a bit harder rocket-wise). 
 From up there, you'd need to project enough power to overcome a path loss that's about 300 to 4000 times worse than what a LEO bird has to contend with, into a much wider band, and over a much larger area. That takes an awful lot of power & antenna gain to do.

The other way round, it's more of an issue: Starlink transmissions, when hitting the high gain antenna of a geostationary receiver on the ground that's close to your Dishy, can drown out the GEO sat. That's why there's an ITU requirement to reduce or cease transmissions if you're a non-GEO sat and you're on the line between your intended receiver and the geostationary orbit.

On 16/01/2026 10:09 am, Hayden Simon wrote:
> Sorry, I was envisaging being above the terminals - above the leo birds (so, in orbit realistically) and then blasting the target area - wide band, high power, just noise, effectively drowning out the starlink birds from the dishy perspective.
>
>
> HAYDEN SIMON
> UBER GROUP LIMITED
> MANAGING DIRECTOR
> E: h@uber.nz
> M: 021 0707 014
> W: www.uber.nz
> 53 PORT ROAD | PO BOX 5083 | WHANGAREI | NEW ZEALAND -----Original 
> Message-----
> From: Ulrich Speidel <u.speidel@auckland.ac.nz>
> Sent: Friday, 16 January 2026 10:07 am
> To: Hayden Simon <h@uber.nz>; starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] Re: Starlink and Iran
>
> On 16/01/2026 9:30 am, Hayden Simon wrote:
>> That leaves the most likely alternative as the action occuring from reasonable altitude. Be that in orbit, weather balloon(s)....drones.
>>
> Not really. Think of a Starlink satellite's beam as a laser pointer 
> pointing at Dishys on the ground that look at the satellite with a 
> good old fashioned telescope (which is what the phased array 
> effectively does). And vice versa (laser pointer at the Dishy, 
> telescope at the satellite). To disrupt that signal, you have to get 
> yourself in front of the telescope with your laser pointer so your 
> interfering signal can even be seen. Getting in front of the 
> telescopes on the ground is mission impossible because there are a few 
> 10000 of them. Moreover, they suddenly switch direction to point at 
> another satellite typically every
> 15 to 75 s (which shorter intervals dominating).
>
> Getting in front of the telescopes on the satellites is somewhat easier as there are fewer of them and - with a drone - you'd be further away and they'd already be pointing in your general direction if you're close to the Dishy you're trying to interfere with. But even so, you'd need one laser pointer per visible and usable satellite - in each cell you're wanting to take Starlink out on. Moreover, you wouldn't know whether the satellite is currently receiving from that cell on a red, blue, or green light frequency - so you'd have to pump power into all of them. Not trivial.
>
> GPS interference is much easier.
>
> --
> ****************************************************************
> 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/
> ****************************************************************
>
>
>
--
****************************************************************
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/
****************************************************************

[Starlink] Re: Starlink and Iran

[David Fernández]

What about this?
https://olegkutkov.me/2023/11/07/connecting-external-gps-antenna-to-the-starlink-terminal

Is an update needed?

From: Ulrich Speidel <u.speidel@auckland.ac.nz>
To: "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
Subject: [Starlink] Starlink and Iran
Date: Thu, 15 Jan 2026 22:51:13 +1300    [thread overview]
Message-ID: <5c0a93c4-21b2-4297-b4bb-befce0963a93@auckland.ac.nz> (raw)

...

For all I know Starlink doesn't
need GPS - while Dishys have GPS receivers, Starlink's got its own
positioning system, too. Also, GPS jamming is fairly common globally and
it's not known to be impairing Starlink all that much.

[Starlink] Re: Starlink and Iran

[Oleg Kutkov]

Some updates from my side: 
https://x.com/olegkutkov/status/2011806875306627491

It's more than enough to activate "Use Starlink positioning exclusively" 
in the advanced settings.
The trick is to flip the switch as soon as possible on the Starlink 
start. Before Starlink acquired some GPS data, the data might have been 
incorrect.

On 1/15/26 16:50, David Fernández via Starlink wrote:
> What about this?
> https://olegkutkov.me/2023/11/07/connecting-external-gps-antenna-to-the-starlink-terminal
>
> Is an update needed?
>
> From: Ulrich Speidel <u.speidel@auckland.ac.nz>
> To: "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
> Subject: [Starlink] Starlink and Iran
> Date: Thu, 15 Jan 2026 22:51:13 +1300    [thread overview]
> Message-ID: <5c0a93c4-21b2-4297-b4bb-befce0963a93@auckland.ac.nz> (raw)
>
> ...
>
> For all I know Starlink doesn't
> need GPS - while Dishys have GPS receivers, Starlink's got its own
> positioning system, too. Also, GPS jamming is fairly common globally and
> it's not known to be impairing Starlink all that much.
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

-- 
Best regards,
Oleg Kutkov

[Starlink] Re: Starlink and Iran

[J Pan]

starlink could make this option persistent across reboot for some
users in some regions
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

On Thu, Jan 15, 2026 at 8:12 AM Oleg Kutkov via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> Some updates from my side:
> https://x.com/olegkutkov/status/2011806875306627491
>
> It's more than enough to activate "Use Starlink positioning exclusively"
> in the advanced settings.
> The trick is to flip the switch as soon as possible on the Starlink
> start. Before Starlink acquired some GPS data, the data might have been
> incorrect.
>
> On 1/15/26 16:50, David Fernández via Starlink wrote:
> > What about this?
> > https://olegkutkov.me/2023/11/07/connecting-external-gps-antenna-to-the-starlink-terminal
> >
> > Is an update needed?
> >
> > From: Ulrich Speidel <u.speidel@auckland.ac.nz>
> > To: "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
> > Subject: [Starlink] Starlink and Iran
> > Date: Thu, 15 Jan 2026 22:51:13 +1300    [thread overview]
> > Message-ID: <5c0a93c4-21b2-4297-b4bb-befce0963a93@auckland.ac.nz> (raw)
> >
> > ...
> >
> > For all I know Starlink doesn't
> > need GPS - while Dishys have GPS receivers, Starlink's got its own
> > positioning system, too. Also, GPS jamming is fairly common globally and
> > it's not known to be impairing Starlink all that much.
> > _______________________________________________
> > Starlink mailing list -- starlink@lists.bufferbloat.net
> > To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>
> --
> Best regards,
> Oleg Kutkov
>
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

[Starlink] Starlink and Iran

[Ulrich Speidel]

I guess you would have all been following the reporting on Iran & how 
Starlink is being used a communication backroute out of the country, but 
also how it's being jammed by the Iranian government. Today, I received 
a petition request from an NGO asking me to sign a petition to get Elon 
to turn on D2C (direct-to-cell) over Iran, and it's phrasing it in such 
a way that it'd "turn the lights on".

My 5 cents worth:

Jamming: Over every location in Iran, there are several dozen Starlink 
satellites visible at any one time that Dishys on the ground can in 
principle communicate with (read: 25 deg plus above the horizon and 
clear of the geostationary arc). There are purportedly tens of thousands 
of Dishys in the country. Each of those Dishys (when working) 
communicates with one of the satellites, and does so by pointing a beam 
at the satellite - which points a beam back. Even two Dishys in close 
vicinity of each other generally talk to different satellites.

To jam communication between a Dishy and a satellite you have to insert 
the jammer into the transmission path - either by pointing it at the 
satellite's receiver, or by pointing it at the Dishy. In either case, 
you want to do so ideally from the direction of the respective 
transmitter that the receiver is listening to, because there isn't all 
that much sensitivity if you're jamming off beam. Basically, because 
signal power drops of with the square of the distance, you need to be 
fairly close to a Dishy in order to out-shout the transmitter at the far 
end of the beam if you're trying to jam from outside the beam.

Jamming the main traffic channels to Dishy is an uphill task - for a 
total blackout, you'd have to cover a good part of the 2 GHz total in 
Ku with sufficient power in terms of spectral density to cause mischief. 
Not easy.

Likewise, pointing your jammer at the satellite(s) is mission impossible 
because there's every chance that the satellites will be listening to 
Dishys that are in a different direction from you.

There would I guess be some opportunity in terms of jamming management 
channels (e.g., access grant channel) but even this is complex with that 
number of satellites around.

Plus those babies move, so you need jammers that can track. And 15 
seconds after you're worked out what you need to point where, Starlink 
changes the game on you.

The Independent quotes "a specialist in digital repression and associate 
director of the Technology Threats and Opportunities Program at Witness" 
https://www.independent.co.uk/news/world/middle-east/iran-internet-blackout-protest-starlink-musk-b2900101.html 
saying that they think it's GPS jamming. For all I know Starlink doesn't 
need GPS - while Dishys have GPS receivers, Starlink's got its own 
positioning system, too. Also, GPS jamming is fairly common globally and 
it's not known to be impairing Starlink all that much.

D2C: Maybe someone should have asked the NZ Commerce Commission for 
advice first. They figured out a long time ago that D2C isn't quite 
there yet (and may never get fully there). It's only capable of 
supporting a comparatively small number of devices per unit area on the 
ground, and apart from a small number of premium phones, with text and 
perhaps RCS/MMS only. And that's with a telco on the ground that's 
actually cooperating and making frequencies available. One NZ, the New 
Zealand telco who partners with SpaceX on the D2C here, had its 
marketing department shouting the virtues from the rooftops until the 
Commerce Commission filed criminal charges. They're still in the game 
but when I bought a new mobile phone the other day, it took me several 
minutes to find the page that listed compatible phones. The service is 
now a little less prominent on their home page - you have to scroll a 
little to find it. Also, word doesn't seem to have gotten around that 
your mobile phone - even if satellite-capable - will connect to 
terrestrial networks with priority. So Iranians would have to go pretty 
far out into the desert just to TXT. Oh, and cellphones are a lot easier 
to jam than Dishys...

Of course, that's not the only consideration here. Using Starlink is 
illegal in Iran, and I guess getting caught with a Dishy is a bit risky 
there at the moment. But RF direction finding 50k+ Dishys that change 
transmit frequency a couple of times a minute isn't trivial: It requires 
specialised equipment and skill, both of which are likely to be in short 
supply at the moment. So I suppose visual identification of Dishys (from 
the air or high rise buildings) might be a more promising tactic. But of 
course they can be camouflaged to an extent as well as moved.

Also, Starlink tends to be more of a technology for underserved rural 
areas rather than cities in countries with high Internet penetration 
rates - which Iran is one of. So it's likely that many of the tens of 
thousands of Dishys are in rural locations where there haven't been any 
large protests.


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

[Starlink] Re: Starlink and Iran

[Inemesit Affia]

Wrt to DTC, you'll need SIM's, e-SIM or physical. Much easier to make and
ship than regular Starlink receiver. 4G requires mutual authentication.

There's more spectrum to use if the towers are switched off as opposed to
not terminating calls.

Maybe it can be delivered as an app store app?

On Thu, Jan 15, 2026, 10:51 AM Ulrich Speidel via Starlink <
starlink@lists.bufferbloat.net> wrote:

> I guess you would have all been following the reporting on Iran & how
> Starlink is being used a communication backroute out of the country, but
> also how it's being jammed by the Iranian government. Today, I received
> a petition request from an NGO asking me to sign a petition to get Elon
> to turn on D2C (direct-to-cell) over Iran, and it's phrasing it in such
> a way that it'd "turn the lights on".
>
> My 5 cents worth:
>
> Jamming: Over every location in Iran, there are several dozen Starlink
> satellites visible at any one time that Dishys on the ground can in
> principle communicate with (read: 25 deg plus above the horizon and
> clear of the geostationary arc). There are purportedly tens of thousands
> of Dishys in the country. Each of those Dishys (when working)
> communicates with one of the satellites, and does so by pointing a beam
> at the satellite - which points a beam back. Even two Dishys in close
> vicinity of each other generally talk to different satellites.
>
> To jam communication between a Dishy and a satellite you have to insert
> the jammer into the transmission path - either by pointing it at the
> satellite's receiver, or by pointing it at the Dishy. In either case,
> you want to do so ideally from the direction of the respective
> transmitter that the receiver is listening to, because there isn't all
> that much sensitivity if you're jamming off beam. Basically, because
> signal power drops of with the square of the distance, you need to be
> fairly close to a Dishy in order to out-shout the transmitter at the far
> end of the beam if you're trying to jam from outside the beam.
>
> Jamming the main traffic channels to Dishy is an uphill task - for a
> total blackout, you'd have to cover a good part of the 2 GHz total in
> Ku with sufficient power in terms of spectral density to cause mischief.
> Not easy.
>
> Likewise, pointing your jammer at the satellite(s) is mission impossible
> because there's every chance that the satellites will be listening to
> Dishys that are in a different direction from you.
>
> There would I guess be some opportunity in terms of jamming management
> channels (e.g., access grant channel) but even this is complex with that
> number of satellites around.
>
> Plus those babies move, so you need jammers that can track. And 15
> seconds after you're worked out what you need to point where, Starlink
> changes the game on you.
>
> The Independent quotes "a specialist in digital repression and associate
> director of the Technology Threats and Opportunities Program at Witness"
>
> https://www.independent.co.uk/news/world/middle-east/iran-internet-blackout-protest-starlink-musk-b2900101.html
> saying that they think it's GPS jamming. For all I know Starlink doesn't
> need GPS - while Dishys have GPS receivers, Starlink's got its own
> positioning system, too. Also, GPS jamming is fairly common globally and
> it's not known to be impairing Starlink all that much.
>
> D2C: Maybe someone should have asked the NZ Commerce Commission for
> advice first. They figured out a long time ago that D2C isn't quite
> there yet (and may never get fully there). It's only capable of
> supporting a comparatively small number of devices per unit area on the
> ground, and apart from a small number of premium phones, with text and
> perhaps RCS/MMS only. And that's with a telco on the ground that's
> actually cooperating and making frequencies available. One NZ, the New
> Zealand telco who partners with SpaceX on the D2C here, had its
> marketing department shouting the virtues from the rooftops until the
> Commerce Commission filed criminal charges. They're still in the game
> but when I bought a new mobile phone the other day, it took me several
> minutes to find the page that listed compatible phones. The service is
> now a little less prominent on their home page - you have to scroll a
> little to find it. Also, word doesn't seem to have gotten around that
> your mobile phone - even if satellite-capable - will connect to
> terrestrial networks with priority. So Iranians would have to go pretty
> far out into the desert just to TXT. Oh, and cellphones are a lot easier
> to jam than Dishys...
>
> Of course, that's not the only consideration here. Using Starlink is
> illegal in Iran, and I guess getting caught with a Dishy is a bit risky
> there at the moment. But RF direction finding 50k+ Dishys that change
> transmit frequency a couple of times a minute isn't trivial: It requires
> specialised equipment and skill, both of which are likely to be in short
> supply at the moment. So I suppose visual identification of Dishys (from
> the air or high rise buildings) might be a more promising tactic. But of
> course they can be camouflaged to an extent as well as moved.
>
> Also, Starlink tends to be more of a technology for underserved rural
> areas rather than cities in countries with high Internet penetration
> rates - which Iran is one of. So it's likely that many of the tens of
> thousands of Dishys are in rural locations where there haven't been any
> large protests.
>
>
> --
> ****************************************************************
> 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/
> ****************************************************************
>
>
>
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>

[Starlink] Re: Starlink and Iran

[Ulrich Speidel]

On 15/01/2026 11:06 pm, Inemesit Affia wrote:
>
> 	
> You don't often get email from inemesitaffia@gmail.com. Learn why this 
> is important <https://aka.ms/LearnAboutSenderIdentification>
> 	
>
> Wrt to DTC, you'll need SIM's, e-SIM or physical. Much easier to make 
> and ship than regular Starlink receiver. 4G requires mutual 
> authentication.

Indeed, but that doesn't address problems related to user density - you 
really can't support tens of thousands of people in a city that way. It 
really only works for a handful of folks in a larger area at a time. 
It's not an easily scalable solution.

One NZ currently handles perhaps a few thousand TXT messages (if that 
many) via satellite a day in a country about 1/6th of the area of Iran 
and are actively rationing the service by making it a premium product 
even though few people can actually physically use it because 
terrestrial coverage is so good. This simply doesn't scale to anywhere 
near the needs of 90M+ Iranians, let alone in a few weeks.

>
> There's more spectrum to use if the towers are switched off as opposed 
> to not terminating calls.
That's supposing someone will do SpaceX a favour and switch the local 
base stations off in large numbers. Not realistic.
>
> Maybe it can be delivered as an app store app?

Getting e-Sims in is the easy part, getting the rest to work is the hard 
bit. D2C for Iran is simply a non-starter - whatever is there in terms 
of Dishys already dwarfs it in terms of capacity by orders of magnitude.

Iranian Internet users do need hope, but a lot of what's circulating out 
there at the moment is hype and people's imagination having gone wild. A 
lot of that is giving false hope, and that's probably the last thing 
people need right now.

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

[Starlink] Re: Starlink and Iran

[Inemesit Affia]

Jan 15, 2026 11:31:04 AM Ulrich Speidel <u.speidel@auckland.ac.nz>:

> On 15/01/2026 11:06 pm, Inemesit Affia wrote:
>> 
>> You don't often get email from inemesitaffia@gmail.com. Learn why this is important[https://aka.ms/LearnAboutSenderIdentification]
>> Wrt to DTC, you'll need SIM's, e-SIM or physical. Much easier to make and ship than regular Starlink receiver. 4G requires mutual authentication.
> 
> Indeed, but that doesn't address problems related to user density - you really can't support tens of thousands of people in a city that way. It really only works for a handful of folks in a larger area at a time. It's not an easily scalable solution.

You don't need to help everyone to be of help.


> 
> 
> One NZ currently handles perhaps a few thousand TXT messages (if that many) via satellite a day in a country about 1/6th of the area of Iran and are actively rationing the service by making it a premium product even though few people can actually physically use it because terrestrial coverage is so good. This simply doesn't scale to anywhere near the needs of 90M+ Iranians, let alone in a few weeks. 
> 
>> 
>> There's more spectrum to use if the towers are switched off as opposed to not terminating calls.
> That's supposing someone will do SpaceX a favour and switch the local base stations off in large numbers. Not realistic.  

I don't think cell providers will keep antennas on unless they are asked to. That's money for power gone. Maybe even fuel given the power outages going on.

I know they may have network slices or whitelists of government users they serve, but otherwise


> 
>> 
>> Maybe it can be delivered as an app store app?
> 
> Getting e-Sims in is the easy part, getting the rest to work is the hard bit. D2C for Iran is simply a non-starter - whatever is there in terms of Dishys already dwarfs it in terms of capacity by orders of magnitude.

There are particular benefits. That you haven't considered. Like the fact the channel is enough for texting and that's enough for the activists that want it. Doesn't have to serve everyone to help everyone.

Any channel that can be text only is enough for DTC.

And it seems you have no idea that T-Mobile has Twitter and WhatsApp working. Disable video with the co-operation of the app makers allowed of they are using a particular IP range and you have a working tool for the aforementioned goals.

But they should have planned this ages ago.
> 
> Iranian Internet users do need hope, but a lot of what's circulating out there at the moment is hype and people's imagination having gone wild. A lot of that is giving false hope, and that's probably the last thing people need right now.
> 
> -- 
> ****************************************************************
> 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/
> ****************************************************************
> 
> 

[Starlink] Re: Starlink and Iran

[Ulrich Speidel]

On 15/01/2026 11:44 pm, Inemesit Affia wrote:
>
> 	
> You don't often get email from inemesitaffia@gmail.com. Learn why this 
> is important <https://aka.ms/LearnAboutSenderIdentification>
> 	
>
> Jan 15, 2026 11:31:04 AM Ulrich Speidel <u.speidel@auckland.ac.nz>:
>
>     On 15/01/2026 11:06 pm, Inemesit Affia wrote:
>
>
>         You don't often get email from inemesitaffia@gmail.com. Learn
>         why this is important
>         <https://aka.ms/LearnAboutSenderIdentification>
>         Wrt to DTC, you'll need SIM's, e-SIM or physical. Much easier
>         to make and ship than regular Starlink receiver. 4G requires
>         mutual authentication.
>
>
>     Indeed, but that doesn't address problems related to user density
>     - you really can't support tens of thousands of people in a city
>     that way. It really only works for a handful of folks in a larger
>     area at a time. It's not an easily scalable solution.
>
>
> You don't need to help everyone to be of help.

Indeed. There may be the odd satellite TXT that could be sent, and it 
might be of help. But that's not what I'm talking about. It's language 
like the sample below that I read today from a well known NGO movement:

> This solution *leverages satellite technology that can connect 
> directly to ordinary mobile phones* – no dishes or internet needed, 
> enabling millions of Iranians to send urgent messages, even during 
> this blackout. *All that’s missing is the political green light to 
> switch it on.*
This is patently rubbish!

Even the Independent writes:

> There are other ways Musk’s company could provide connectivity to a 
> far larger number of people across Iran – but it would be costly, and 
> it is unclear how it would be funded. 
Now the context in which this paragraph stands makes it clear that the 
"far larger number" is that of the people who would be able to use D2C 
compared to the number using Dishys. That's equally rubbish.

>
>
>
>
>
>     One NZ currently handles perhaps a few thousand TXT messages (if
>     that many) via satellite a day in a country about 1/6th of the
>     area of Iran and are actively rationing the service by making it a
>     premium product even though few people can actually physically use
>     it because terrestrial coverage is so good. This simply doesn't
>     scale to anywhere near the needs of 90M+ Iranians, let alone in a
>     few weeks.
>
>
>         There's more spectrum to use if the towers are switched off as
>         opposed to not terminating calls.
>
>     That's supposing someone will do SpaceX a favour and switch the
>     local base stations off in large numbers. Not realistic.
>
>
> I don't think cell providers will keep antennas on unless they are 
> asked to. That's money for power gone. Maybe even fuel given the power 
> outages going on.
I think they might just be asked to do exactly that, precisely to ensure 
phones associate with their networks and that spectrum is taken. And 
fuel isn't in short supply in Iran.
>
>
> I know they may have network slices or whitelists of government users 
> they serve, but otherwise
Indeed.
>
>
>     Getting e-Sims in is the easy part, getting the rest to work is
>     the hard bit. D2C for Iran is simply a non-starter - whatever is
>     there in terms of Dishys already dwarfs it in terms of capacity by
>     orders of magnitude.
>
>
> There are particular benefits. That you haven't considered. Like the 
> fact the channel is enough for texting and that's enough for the 
> activists that want it. Doesn't have to serve everyone to help everyone.
The activists are mostly in town, where they'd be connecting / 
interfered with by the terrestrial networks. I suppose that hardy ones 
could travel for dozens of miles to zones outside terrestrial coverage 
to do their satellite text thing, but it's probably easier and faster to 
find someone with a Dishy in Tehran who can help dispatch a much larger 
message or video that way.
>
>
> And it seems you have no idea that T-Mobile has Twitter and WhatsApp 
> working. Disable video with the co-operation of the app makers allowed 
> of they are using a particular IP range and you have a working tool 
> for the aforementioned goals.

Actually I do ... they operate pretty much in lockstep with SpaceX's 
other mobile partners. Note I mentioned the few premium phones on which 
"data" also works. In NZ, these are, as of today:

  * Most iPhones from 13 mini upwards
  * Samsung Galaxy Z Fold7, Flip7, Flip 7FE

I'm not sure how many of these you'd find in Iran right now. But maybe 
it can be extended to other models there.

The apps you can use here are pretty much the same as for T-Mobile.

>
> But they should have planned this ages ago.
>
>
>     Iranian Internet users do need hope, but a lot of what's
>     circulating out there at the moment is hype and people's
>     imagination having gone wild. A lot of that is giving false hope,
>     and that's probably the last thing people need right now.
>
>     -- 
>     ****************************************************************
>     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/
>     ****************************************************************
>
>
>
-- 
****************************************************************
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/
****************************************************************

[Starlink] Re: Starlink and Iran

[Inemesit Affia]

Something more about d2c and other things.

In 4G the network can limit services to say SMS only. Or calls only. But once you give the phone access to IP, the phone is responsible for limiting itself. Hence satellite enabled apps. Without this we've seen people do speed tests on the DTC network.

More spectrum in use means more power or sometimes more equipment to do jamming. Only GPS and the Ku uplink seem to be jammed.

Expertise for RF work doesn't have to be local. Huawei is a world leader. And I'm sure you're familiar with expats.

As for underserved areas, Starlink may be advertised as a rural service, but in poorer countries, most users aren't just suburban but actually Urban

Jan 15, 2026 10:51:32 AM Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net>:

> I guess you would have all been following the reporting on Iran & how Starlink is being used a communication backroute out of the country, but also how it's being jammed by the Iranian government. Today, I received a petition request from an NGO asking me to sign a petition to get Elon to turn on D2C (direct-to-cell) over Iran, and it's phrasing it in such a way that it'd "turn the lights on".
> 
> My 5 cents worth:
> 
> Jamming: Over every location in Iran, there are several dozen Starlink satellites visible at any one time that Dishys on the ground can in principle communicate with (read: 25 deg plus above the horizon and clear of the geostationary arc). There are purportedly tens of thousands of Dishys in the country. Each of those Dishys (when working) communicates with one of the satellites, and does so by pointing a beam at the satellite - which points a beam back. Even two Dishys in close vicinity of each other generally talk to different satellites.
> 
> To jam communication between a Dishy and a satellite you have to insert the jammer into the transmission path - either by pointing it at the satellite's receiver, or by pointing it at the Dishy. In either case, you want to do so ideally from the direction of the respective transmitter that the receiver is listening to, because there isn't all that much sensitivity if you're jamming off beam. Basically, because signal power drops of with the square of the distance, you need to be fairly close to a Dishy in order to out-shout the transmitter at the far end of the beam if you're trying to jam from outside the beam.
> 
> Jamming the main traffic channels to Dishy is an uphill task - for a total blackout, you'd have to cover a good part of the 2 GHz total in Ku with sufficient power in terms of spectral density to cause mischief. Not easy.
> 
> Likewise, pointing your jammer at the satellite(s) is mission impossible because there's every chance that the satellites will be listening to Dishys that are in a different direction from you.
> 
> There would I guess be some opportunity in terms of jamming management channels (e.g., access grant channel) but even this is complex with that number of satellites around.
> 
> Plus those babies move, so you need jammers that can track. And 15 seconds after you're worked out what you need to point where, Starlink changes the game on you.
> 
> The Independent quotes "a specialist in digital repression and associate director of the Technology Threats and Opportunities Program at Witness" https://www.independent.co.uk/news/world/middle-east/iran-internet-blackout-protest-starlink-musk-b2900101.html saying that they think it's GPS jamming. For all I know Starlink doesn't need GPS - while Dishys have GPS receivers, Starlink's got its own positioning system, too. Also, GPS jamming is fairly common globally and it's not known to be impairing Starlink all that much.
> 
> D2C: Maybe someone should have asked the NZ Commerce Commission for advice first. They figured out a long time ago that D2C isn't quite there yet (and may never get fully there). It's only capable of supporting a comparatively small number of devices per unit area on the ground, and apart from a small number of premium phones, with text and perhaps RCS/MMS only. And that's with a telco on the ground that's actually cooperating and making frequencies available. One NZ, the New Zealand telco who partners with SpaceX on the D2C here, had its marketing department shouting the virtues from the rooftops until the Commerce Commission filed criminal charges. They're still in the game but when I bought a new mobile phone the other day, it took me several minutes to find the page that listed compatible phones. The service is now a little less prominent on their home page - you have to scroll a little to find it. Also, word doesn't seem to have gotten around that your mobile phone - even if satellite-capable - will connect to terrestrial networks with priority. So Iranians would have to go pretty far out into the desert just to TXT. Oh, and cellphones are a lot easier to jam than Dishys...
> 
> Of course, that's not the only consideration here. Using Starlink is illegal in Iran, and I guess getting caught with a Dishy is a bit risky there at the moment. But RF direction finding 50k+ Dishys that change transmit frequency a couple of times a minute isn't trivial: It requires specialised equipment and skill, both of which are likely to be in short supply at the moment. So I suppose visual identification of Dishys (from the air or high rise buildings) might be a more promising tactic. But of course they can be camouflaged to an extent as well as moved.
> 
> Also, Starlink tends to be more of a technology for underserved rural areas rather than cities in countries with high Internet penetration rates - which Iran is one of. So it's likely that many of the tens of thousands of Dishys are in rural locations where there haven't been any large protests.
> 
> 
> -- 
> ****************************************************************
> 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/
> ****************************************************************
> 
> 
> 
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

[Starlink] Re: Starlink and Iran

[Ulrich Speidel]

On 15/01/2026 11:32 pm, Inemesit Affia wrote:
>
> 	
> You don't often get email from inemesitaffia@gmail.com. Learn why this 
> is important <https://aka.ms/LearnAboutSenderIdentification>
> 	
>
> Something more about d2c and other things.
>
> In 4G the network can limit services to say SMS only. Or calls only. 
> But once you give the phone access to IP, the phone is responsible for 
> limiting itself. Hence satellite enabled apps. Without this we've seen 
> people do speed tests on the DTC network.
>
> More spectrum in use means more power or sometimes more equipment to 
> do jamming. Only GPS and the Ku uplink seem to be jammed.

Ku uplink would be the easier target but you'd have to have a lot of 
jammers (one per sat you want to jam), all with tracking antennas, and 
it'd pretty much work for a cell (or perhaps cell cluster) at a time - 
you'd need a separate set for each city I guess.

BTW I should have said "access request channel" not "access grant channel".

>
>
> Expertise for RF work doesn't have to be local. Huawei is a world 
> leader. And I'm sure you're familiar with expats.
I was referring to people who'd go track down Dishys locally by RF 
direction finding ... so having an expert in China doesn't really help 
here. That needs boots on the ground.
>
>
> As for underserved areas, Starlink may be advertised as a rural 
> service, but in poorer countries, most users aren't just suburban but 
> actually Urban

True - Manila is a great example for this, and there are others. But 
Iranian cities are not. Iran was targeting 20 million households and 
businesses on fibre by the end of last year, and of course there was 
mobile Internet on top of that.

I'm sure there would have been a segment of urban users also, 
specifically to get at otherwise firewalled content.


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

[Starlink] Re: Starlink and Iran

[David Lang]

Authorized or not, starlink service has been turned on in Iran, I would assume 
that D2C is enabled as well.

D2C is not going to be good for livestreaming video, it will support text and 
voice communications

Jamming the D2C signal is far easier than jamming the dishys, all you need is 
to have the towers running with a stronger signal. (the phones will connect to 
the tower with the strongest signal). It's also easier to jam the D2C satellites 
(wider beamwidth and fewer that need to be jammed)

I don't think they would need to get new sims, esims, etc in place, they just 
need to instruct the satellites to accept any sim rather than only authorized 
sims.

creative use of aluminum foil should be able to shield your phone from the 
ground based towers, leaving them nothing other than the satellites for the 
phone to connect to (this will also block bluetooth, but wired connections to 
the phones will work)


In terms of tracking/jamming the dishys normal signal, I think it would be 
easier to track/jam their wifi signal, those default to SSID STARLINK and will 
be in a known MAC range. disabling wifi and only working with a wired connection 
is going to be much safer (admittedly, less convienient, but when they are 
threatening to kill you if you use a dishy, you should batch upload via a wired 
connection, not try to livestream the protests, at least, not unless you are 
truely mobile)

At the beginning of the invasion of Ukraine, Elon said that people needed to be 
careful, have a hill or other obstruction between the dishy and the bad guys, 
don't leave it running all the time, etc (basic signal security)

I have seen reports that SpaceX is in all-hands-on-deck mode to work to defeat 
the jammers. I expect that this will include things like pointing the beams at 
different dishy cells than they normally would use, etc.

I could see GPS jamming being a problem, if the dishy thinks it's somewhere 
other than where it really is, how successful will it be in connecting to the 
right satellites?? there are ways to work around this, and that may also be what 
starlink is working on.

David Lang



Ulrich Speidel wrote:

> Jamming: Over every location in Iran, there are several dozen Starlink 
> satellites visible at any one time that Dishys on the ground can in principle 
> communicate with (read: 25 deg plus above the horizon and clear of the 
> geostationary arc). There are purportedly tens of thousands of Dishys in the 
> country. Each of those Dishys (when working) communicates with one of the 
> satellites, and does so by pointing a beam at the satellite - which points a 
> beam back. Even two Dishys in close vicinity of each other generally talk to 
> different satellites.
>
> To jam communication between a Dishy and a satellite you have to insert the 
> jammer into the transmission path - either by pointing it at the satellite's 
> receiver, or by pointing it at the Dishy. In either case, you want to do so 
> ideally from the direction of the respective transmitter that the receiver is 
> listening to, because there isn't all that much sensitivity if you're jamming 
> off beam. Basically, because signal power drops of with the square of the 
> distance, you need to be fairly close to a Dishy in order to out-shout the 
> transmitter at the far end of the beam if you're trying to jam from outside 
> the beam.
>
> Jamming the main traffic channels to Dishy is an uphill task - for a total 
> blackout, you'd have to cover a good part of the 2 GHz total in Ku with 
> sufficient power in terms of spectral density to cause mischief. Not easy.
>
> Likewise, pointing your jammer at the satellite(s) is mission impossible 
> because there's every chance that the satellites will be listening to Dishys 
> that are in a different direction from you.
>
> There would I guess be some opportunity in terms of jamming management 
> channels (e.g., access grant channel) but even this is complex with that 
> number of satellites around.
>
> Plus those babies move, so you need jammers that can track. And 15 seconds 
> after you're worked out what you need to point where, Starlink changes the 
> game on you.
>
> The Independent quotes "a specialist in digital repression and associate 
> director of the Technology Threats and Opportunities Program at Witness" 
> https://www.independent.co.uk/news/world/middle-east/iran-internet-blackout-protest-starlink-musk-b2900101.html 
> saying that they think it's GPS jamming. For all I know Starlink doesn't need 
> GPS - while Dishys have GPS receivers, Starlink's got its own positioning 
> system, too. Also, GPS jamming is fairly common globally and it's not known 
> to be impairing Starlink all that much.
>
> D2C: Maybe someone should have asked the NZ Commerce Commission for advice 
> first. They figured out a long time ago that D2C isn't quite there yet (and 
> may never get fully there). It's only capable of supporting a comparatively 
> small number of devices per unit area on the ground, and apart from a small 
> number of premium phones, with text and perhaps RCS/MMS only. And that's with 
> a telco on the ground that's actually cooperating and making frequencies 
> available. One NZ, the New Zealand telco who partners with SpaceX on the D2C 
> here, had its marketing department shouting the virtues from the rooftops 
> until the Commerce Commission filed criminal charges. They're still in the 
> game but when I bought a new mobile phone the other day, it took me several 
> minutes to find the page that listed compatible phones. The service is now a 
> little less prominent on their home page - you have to scroll a little to 
> find it. Also, word doesn't seem to have gotten around that your mobile phone 
> - even if satellite-capable - will connect to terrestrial networks with 
> priority. So Iranians would have to go pretty far out into the desert just to 
> TXT. Oh, and cellphones are a lot easier to jam than Dishys...
>
> Of course, that's not the only consideration here. Using Starlink is illegal 
> in Iran, and I guess getting caught with a Dishy is a bit risky there at the 
> moment. But RF direction finding 50k+ Dishys that change transmit frequency a 
> couple of times a minute isn't trivial: It requires specialised equipment and 
> skill, both of which are likely to be in short supply at the moment. So I 
> suppose visual identification of Dishys (from the air or high rise buildings) 
> might be a more promising tactic. But of course they can be camouflaged to an 
> extent as well as moved.
>
> Also, Starlink tends to be more of a technology for underserved rural areas 
> rather than cities in countries with high Internet penetration rates - which 
> Iran is one of. So it's likely that many of the tens of thousands of Dishys 
> are in rural locations where there haven't been any large protests.
>
>
>

[Starlink] Re: Starlink and Iran

[Sauli Kiviranta]

"I have seen reports that SpaceX is in all-hands-on-deck mode to work to
defeat
the jammers. I expect that this will include things like pointing the beams
at
different dishy cells than they normally would use, etc."

Do we have any technical characteristics about the jamming how it is
visible to the application layer? I saw some X posts talk about 20% packet
loss, some said 80%.

Anyone from SpaceX can comment on what is the challenge "requirements" for
contributions?

Best regards,
Sauli

On Thu, Jan 15, 2026 at 1:17 PM David Lang via Starlink <
starlink@lists.bufferbloat.net> wrote:

> Authorized or not, starlink service has been turned on in Iran, I would
> assume
> that D2C is enabled as well.
>
> D2C is not going to be good for livestreaming video, it will support text
> and
> voice communications
>
> Jamming the D2C signal is far easier than jamming the dishys, all you need
> is
> to have the towers running with a stronger signal. (the phones will
> connect to
> the tower with the strongest signal). It's also easier to jam the D2C
> satellites
> (wider beamwidth and fewer that need to be jammed)
>
> I don't think they would need to get new sims, esims, etc in place, they
> just
> need to instruct the satellites to accept any sim rather than only
> authorized
> sims.
>
> creative use of aluminum foil should be able to shield your phone from the
> ground based towers, leaving them nothing other than the satellites for
> the
> phone to connect to (this will also block bluetooth, but wired connections
> to
> the phones will work)
>
>
> In terms of tracking/jamming the dishys normal signal, I think it would be
> easier to track/jam their wifi signal, those default to SSID STARLINK and
> will
> be in a known MAC range. disabling wifi and only working with a wired
> connection
> is going to be much safer (admittedly, less convienient, but when they are
> threatening to kill you if you use a dishy, you should batch upload via a
> wired
> connection, not try to livestream the protests, at least, not unless you
> are
> truely mobile)
>
> At the beginning of the invasion of Ukraine, Elon said that people needed
> to be
> careful, have a hill or other obstruction between the dishy and the bad
> guys,
> don't leave it running all the time, etc (basic signal security)
>
> I have seen reports that SpaceX is in all-hands-on-deck mode to work to
> defeat
> the jammers. I expect that this will include things like pointing the
> beams at
> different dishy cells than they normally would use, etc.
>
> I could see GPS jamming being a problem, if the dishy thinks it's
> somewhere
> other than where it really is, how successful will it be in connecting to
> the
> right satellites?? there are ways to work around this, and that may also
> be what
> starlink is working on.
>
> David Lang
>
>
>
> Ulrich Speidel wrote:
>
> > Jamming: Over every location in Iran, there are several dozen Starlink
> > satellites visible at any one time that Dishys on the ground can in
> principle
> > communicate with (read: 25 deg plus above the horizon and clear of the
> > geostationary arc). There are purportedly tens of thousands of Dishys in
> the
> > country. Each of those Dishys (when working) communicates with one of
> the
> > satellites, and does so by pointing a beam at the satellite - which
> points a
> > beam back. Even two Dishys in close vicinity of each other generally
> talk to
> > different satellites.
> >
> > To jam communication between a Dishy and a satellite you have to insert
> the
> > jammer into the transmission path - either by pointing it at the
> satellite's
> > receiver, or by pointing it at the Dishy. In either case, you want to do
> so
> > ideally from the direction of the respective transmitter that the
> receiver is
> > listening to, because there isn't all that much sensitivity if you're
> jamming
> > off beam. Basically, because signal power drops of with the square of
> the
> > distance, you need to be fairly close to a Dishy in order to out-shout
> the
> > transmitter at the far end of the beam if you're trying to jam from
> outside
> > the beam.
> >
> > Jamming the main traffic channels to Dishy is an uphill task - for a
> total
> > blackout, you'd have to cover a good part of the 2 GHz total in Ku with
> > sufficient power in terms of spectral density to cause mischief. Not
> easy.
> >
> > Likewise, pointing your jammer at the satellite(s) is mission impossible
> > because there's every chance that the satellites will be listening to
> Dishys
> > that are in a different direction from you.
> >
> > There would I guess be some opportunity in terms of jamming management
> > channels (e.g., access grant channel) but even this is complex with that
> > number of satellites around.
> >
> > Plus those babies move, so you need jammers that can track. And 15
> seconds
> > after you're worked out what you need to point where, Starlink changes
> the
> > game on you.
> >
> > The Independent quotes "a specialist in digital repression and associate
> > director of the Technology Threats and Opportunities Program at Witness"
> >
> https://www.independent.co.uk/news/world/middle-east/iran-internet-blackout-protest-starlink-musk-b2900101.html
> > saying that they think it's GPS jamming. For all I know Starlink doesn't
> need
> > GPS - while Dishys have GPS receivers, Starlink's got its own
> positioning
> > system, too. Also, GPS jamming is fairly common globally and it's not
> known
> > to be impairing Starlink all that much.
> >
> > D2C: Maybe someone should have asked the NZ Commerce Commission for
> advice
> > first. They figured out a long time ago that D2C isn't quite there yet
> (and
> > may never get fully there). It's only capable of supporting a
> comparatively
> > small number of devices per unit area on the ground, and apart from a
> small
> > number of premium phones, with text and perhaps RCS/MMS only. And that's
> with
> > a telco on the ground that's actually cooperating and making frequencies
> > available. One NZ, the New Zealand telco who partners with SpaceX on the
> D2C
> > here, had its marketing department shouting the virtues from the
> rooftops
> > until the Commerce Commission filed criminal charges. They're still in
> the
> > game but when I bought a new mobile phone the other day, it took me
> several
> > minutes to find the page that listed compatible phones. The service is
> now a
> > little less prominent on their home page - you have to scroll a little
> to
> > find it. Also, word doesn't seem to have gotten around that your mobile
> phone
> > - even if satellite-capable - will connect to terrestrial networks with
> > priority. So Iranians would have to go pretty far out into the desert
> just to
> > TXT. Oh, and cellphones are a lot easier to jam than Dishys...
> >
> > Of course, that's not the only consideration here. Using Starlink is
> illegal
> > in Iran, and I guess getting caught with a Dishy is a bit risky there at
> the
> > moment. But RF direction finding 50k+ Dishys that change transmit
> frequency a
> > couple of times a minute isn't trivial: It requires specialised
> equipment and
> > skill, both of which are likely to be in short supply at the moment. So
> I
> > suppose visual identification of Dishys (from the air or high rise
> buildings)
> > might be a more promising tactic. But of course they can be camouflaged
> to an
> > extent as well as moved.
> >
> > Also, Starlink tends to be more of a technology for underserved rural
> areas
> > rather than cities in countries with high Internet penetration rates -
> which
> > Iran is one of. So it's likely that many of the tens of thousands of
> Dishys
> > are in rural locations where there haven't been any large protests.
> >
> >
> >
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>

[Starlink] Re: Starlink and Iran

[David Lang]

Sauli Kiviranta wrote:

> "I have seen reports that SpaceX is in all-hands-on-deck mode to work to 
> defeat the jammers. I expect that this will include things like pointing the 
> beams at different dishy cells than they normally would use, etc."
>
> Do we have any technical characteristics about the jamming how it is
> visible to the application layer? I saw some X posts talk about 20% packet
> loss, some said 80%.
>
> Anyone from SpaceX can comment on what is the challenge "requirements" for
> contributions?

I would not expect this information to be made public. Finding out what SpaceX 
is trying (and even finding out how SpaceX categorizes the attacks as hard/easy 
to deal with) would be valuable information for those trying to block the 
signal.

David Lang

[Starlink] Re: Starlink and Iran

[Sauli Kiviranta]

X posts by Grok:

”Various sources report widely differing levels of packet loss affecting
Starlink connections in Iran during the January 2026 internet blackouts and
protests. Reported figures range from roughly 20% to more than 80%,
depending on location, timing, and source. This variability is most
plausibly explained by localized jamming and interference efforts, which
appear to impact specific neighborhoods or regions more severely than
others rather than producing uniform nationwide disruption. The claims
below are grouped by reported packet-loss ranges and are drawn from media
reports, technical analyses, and social media posts that explicitly
reference packet loss measurements or estimates, often based on user
reports, NetBlocks monitoring, or expert commentary.


Claims of 20–22% packet loss

Research cited by bne IntelliNews reports sustained packet loss of
approximately 20–22% over five-minute sampling windows in tested areas,
compared with Starlink’s typical baseline of under 1%. These losses were
attributed primarily to GPS spoofing attacks.

Claims of approximately 30% packet loss

Several outlets and analysts report packet loss around 30% in affected
areas. TechRadar describes degraded Starlink performance reaching roughly
this level due to jamming. Multiple X posts, including those by
@Intelligencer41 and @NuclearID68, cite figures near 30%, often attributing
the data to digital rights researcher Amir Rashidi or the Miaan Group.
These reports generally describe averages or moderate interference rather
than worst-case conditions.

Claims of 30–40% packet loss

Euronews reports packet loss of up to 40% in parts of Tehran, likely caused
by mobile jamming equipment deployed in urban areas.

Claims of 30–80% packet loss

A number of sources describe much wider ranges, with packet loss varying
between 30% and 80% depending on time and place. France 24 and Ars Technica
both report losses within this range, attributing them to state-sponsored
jamming technologies. Similar figures appear in user discussions on Reddit
and in reporting by Techflowpost, which notes averages around 30% on the
first day of the blackout but spikes up to 80% in some locations. Multiple
X posts echo this pattern, emphasizing strong geographic variability and
particularly severe impacts in dense urban neighborhoods.

Claims of 80% or higher packet loss

The highest figures appear in reports describing intensive or
military-grade jamming. Forbes, cited via social media, reports disruptions
affecting roughly 80–90% of Starlink traffic in some contexts. Other
claims, based largely on anonymous user reports or social media posts, also
suggest packet loss exceeding 80% during peak interference periods.

Broader context

NetBlocks, referenced across several reports and posts, confirms elevated
packet loss and unstable Starlink connectivity during the blackout period,
though it does not always provide precise percentages. Other cybersecurity
reporting notes sharp increases in packet loss linked to GPS and RF jamming
without quantifying exact levels. Several sources attribute the
interference technology to Russian- or Chinese-supplied systems, while
emphasizing that effectiveness varies substantially by region.


Overall, lower reported figures in the 20–30% range generally reflect
averages or less-affected areas, whereas higher figures, reaching 80–90%,
appear to correspond to localized hotspots, particularly in parts of
Tehran. The estimates rely on user-submitted measurements, network
monitoring tools such as Cloudflare Radar, and expert analysis.”

20% is not that bad, but 80% starts to be a bit 😅

- Sauli

On Thursday, January 15, 2026, David Lang <david@lang.hm> wrote:

> Sauli Kiviranta wrote:
>
> "I have seen reports that SpaceX is in all-hands-on-deck mode to work to
>> defeat the jammers. I expect that this will include things like pointing
>> the beams at different dishy cells than they normally would use, etc."
>>
>> Do we have any technical characteristics about the jamming how it is
>> visible to the application layer? I saw some X posts talk about 20% packet
>> loss, some said 80%.
>>
>> Anyone from SpaceX can comment on what is the challenge "requirements" for
>> contributions?
>>
>
> I would not expect this information to be made public. Finding out what
> SpaceX is trying (and even finding out how SpaceX categorizes the attacks
> as hard/easy to deal with) would be valuable information for those trying
> to block the signal.
>
> David Lang
>

[Starlink] Re: Starlink and Iran

[Inemesit Affia]

Sorry I've messed up the flow in my client

Jan 15, 2026 5:18:16 PM Inemesit Affia <inemesitaffia@gmail.com>:

> Jan 15, 2026 3:06:39 PM David Lang <david@lang.hm>:
> 
>> Inemesit Affia wrote:
>> 
>>> Jan 15, 2026 12:17:46 PM David Lang via Starlink <starlink@lists.bufferbloat.net>:
>>> 
>>>> Authorized or not, starlink service has been turned on in Iran, I would assume that D2C is enabled as well.
>>> 
>>> If it was enabled these people asking for it aren't in the group.
>> 
>> It's been publicly reported that Starlink is active.
> 
> I'm talking about direct to cell. That's what the letter is about. Starlink broadband has been available in Iran since at least Q4 2022.
> 
> 
>> 
>>>> Jamming the D2C signal is far easier than jamming the dishys, all you need is to have the towers running with a stronger signal. (the phones will connect to the tower with the strongest signal). It's also easier to jam the D2C satellites (wider beamwidth and fewer that need to be jammed)
>>> 
>>> True. Hopefully there are free bands somewhere.
>> 
>> D2C only operates on a single band.
> 
> I don't believe this is true
> 
> PCS G Block LTE band 25(1910-1915 MHz & 1990-1995 MHz) is T-Mobile's implementation
> 
> VMO2 1710-1716 UL /MSS  2170-2200 DL (Band 66)
> 
> Softbank 1975-1980 UL / MSS  2170-2200 DL (Band 65)
> 
> DoCoMo 1940-1945 UL / MSS  2170-2200 DL (Band 65)
> 
> KDDI  1920-1925 UL /  MSS 2170-2200 DL (Band 65)
> 
> The tech is capable of 1.6 GHz to at least 2.2 GHz from examples given here. That spans multiple LTE bands. I don't know what else it's capable of. If service is switched off or there are unallocated bands, then there's hope for urban use.
> 
>> 
>> 
>>>> I don't think they would need to get new sims, esims, etc in place, they just need to instruct the satellites to accept any sim rather than only authorized sims.
>>> 
>>> I just don't think this will work. Authorization free 4G.
>> 
>> Why not? just hard code success for the authorization step.
> 
> From what I retained from seminars around the introduction of 4G, the SIM authenticates the network and the network authenticates the Sim using a key stored in the SIM's HSM.
> 
> 911/112 of course excepted
> 
>> 
>> 
>> 
>>>> In terms of tracking/jamming the dishys normal signal, I think it would be easier to track/jam their wifi signal, those default to SSID STARLINK and will be in a known MAC range. disabling wifi and only working with a wired connection is going to be much safer (admittedly, less convienient, but when they are threatening to kill you if you use a dishy, you should batch upload via a wired connection, not try to livestream the protests, at least, not unless you are truely mobile)
>>> 
>>> I've suggested not using the Wi-Fi router at all. Any phone scanner would probably tell you it's a starlink. SpaceX should change the BSSID's too
>> 
>> The SSID can be set by the user, the MAC address is hard-coded
>> 
>> David Lang
> 
>> 
> MAC's can be changed in software. I've done it on Windows XP and 7 ages ago with smac. I'm sure it's doable on Linux. I remember doing similar with HOSTAPD. 
> 
> Remember how devices rotate MAC addresses for privacy? That requires a method for changing them. It's not like the ROM is overwritten. Once the device is reset, it will go back to default.
> 
> 
>>  

[Starlink] Re: Starlink and Iran

[Ulrich Speidel]

On 16/01/2026 12:17 am, David Lang wrote:
>
> In terms of tracking/jamming the dishys normal signal, I think it 
> would be easier to track/jam their wifi signal, those default to SSID 
> STARLINK and will be in a known MAC range. disabling wifi and only 
> working with a wired connection is going to be much safer (admittedly, 
> less convienient, but when they are threatening to kill you if you use 
> a dishy, you should batch upload via a wired connection, not try to 
> livestream the protests, at least, not unless you are truely mobile)

That's a good point, but the SSID is easily changed of course and I 
guess the MAC range part could be addressed via an OTA update (which 
SpaceX know how to do).

That said, the router Wi-Fi signal is really quite limited in range. If 
one keeps it indoors and maybe wrapped in some aluminium foil, its range 
is metres at most. Enough to do uploading when you're home but not 
enough to do DF-ing from the outside.

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

[Starlink] Re: Starlink and Iran

[J Pan]

easier to attack gps?
https://github.com/narimangharib/starlink-iran-gps-spoofing/blob/main/starlink-iran.md
although not all technically correct. "inhibitGps" is a user choice
through the mobile app ("Use Starlink positioning exclusively") not
system determination, but gps spoofing is indeed there. starlink could
be authorized to decode military-grade gps signals as well?
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan


On Thu, Jan 15, 2026 at 1:51 AM Ulrich Speidel via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> I guess you would have all been following the reporting on Iran & how
> Starlink is being used a communication backroute out of the country, but
> also how it's being jammed by the Iranian government. Today, I received
> a petition request from an NGO asking me to sign a petition to get Elon
> to turn on D2C (direct-to-cell) over Iran, and it's phrasing it in such
> a way that it'd "turn the lights on".
>
> My 5 cents worth:
>
> Jamming: Over every location in Iran, there are several dozen Starlink
> satellites visible at any one time that Dishys on the ground can in
> principle communicate with (read: 25 deg plus above the horizon and
> clear of the geostationary arc). There are purportedly tens of thousands
> of Dishys in the country. Each of those Dishys (when working)
> communicates with one of the satellites, and does so by pointing a beam
> at the satellite - which points a beam back. Even two Dishys in close
> vicinity of each other generally talk to different satellites.
>
> To jam communication between a Dishy and a satellite you have to insert
> the jammer into the transmission path - either by pointing it at the
> satellite's receiver, or by pointing it at the Dishy. In either case,
> you want to do so ideally from the direction of the respective
> transmitter that the receiver is listening to, because there isn't all
> that much sensitivity if you're jamming off beam. Basically, because
> signal power drops of with the square of the distance, you need to be
> fairly close to a Dishy in order to out-shout the transmitter at the far
> end of the beam if you're trying to jam from outside the beam.
>
> Jamming the main traffic channels to Dishy is an uphill task - for a
> total blackout, you'd have to cover a good part of the 2 GHz total in
> Ku with sufficient power in terms of spectral density to cause mischief.
> Not easy.
>
> Likewise, pointing your jammer at the satellite(s) is mission impossible
> because there's every chance that the satellites will be listening to
> Dishys that are in a different direction from you.
>
> There would I guess be some opportunity in terms of jamming management
> channels (e.g., access grant channel) but even this is complex with that
> number of satellites around.
>
> Plus those babies move, so you need jammers that can track. And 15
> seconds after you're worked out what you need to point where, Starlink
> changes the game on you.
>
> The Independent quotes "a specialist in digital repression and associate
> director of the Technology Threats and Opportunities Program at Witness"
> https://www.independent.co.uk/news/world/middle-east/iran-internet-blackout-protest-starlink-musk-b2900101.html
> saying that they think it's GPS jamming. For all I know Starlink doesn't
> need GPS - while Dishys have GPS receivers, Starlink's got its own
> positioning system, too. Also, GPS jamming is fairly common globally and
> it's not known to be impairing Starlink all that much.
>
> D2C: Maybe someone should have asked the NZ Commerce Commission for
> advice first. They figured out a long time ago that D2C isn't quite
> there yet (and may never get fully there). It's only capable of
> supporting a comparatively small number of devices per unit area on the
> ground, and apart from a small number of premium phones, with text and
> perhaps RCS/MMS only. And that's with a telco on the ground that's
> actually cooperating and making frequencies available. One NZ, the New
> Zealand telco who partners with SpaceX on the D2C here, had its
> marketing department shouting the virtues from the rooftops until the
> Commerce Commission filed criminal charges. They're still in the game
> but when I bought a new mobile phone the other day, it took me several
> minutes to find the page that listed compatible phones. The service is
> now a little less prominent on their home page - you have to scroll a
> little to find it. Also, word doesn't seem to have gotten around that
> your mobile phone - even if satellite-capable - will connect to
> terrestrial networks with priority. So Iranians would have to go pretty
> far out into the desert just to TXT. Oh, and cellphones are a lot easier
> to jam than Dishys...
>
> Of course, that's not the only consideration here. Using Starlink is
> illegal in Iran, and I guess getting caught with a Dishy is a bit risky
> there at the moment. But RF direction finding 50k+ Dishys that change
> transmit frequency a couple of times a minute isn't trivial: It requires
> specialised equipment and skill, both of which are likely to be in short
> supply at the moment. So I suppose visual identification of Dishys (from
> the air or high rise buildings) might be a more promising tactic. But of
> course they can be camouflaged to an extent as well as moved.
>
> Also, Starlink tends to be more of a technology for underserved rural
> areas rather than cities in countries with high Internet penetration
> rates - which Iran is one of. So it's likely that many of the tens of
> thousands of Dishys are in rural locations where there haven't been any
> large protests.
>
>
> --
> ****************************************************************
> 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/
> ****************************************************************
>
>
>
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

[Starlink] Re: Starlink and Iran

[Ulrich Speidel]

Military-grade GPS kind of lost its exclusivity a long time ago when 
people came up with DGPS (differential GPS), where a local reference 
station with known position transmits a "delta" signal to the GPS signal 
received at that location. And then of course came GLONASS & Co., so 
there's currently about four GPS-like systems out there, and most modern 
receivers support all. That said - these signals can all be interfered 
with and spoofed.

For Starlink, precision location isn't actually required (it's enough 
for Dishy to know which cell it's in because that determines the 
beams).  But GPS receiver chips are cheap and extra position accuracy 
doesn't do any harm.

On 16/01/2026 6:10 am, J Pan wrote:
> easier to attack gps?
> https://github.com/narimangharib/starlink-iran-gps-spoofing/blob/main/starlink-iran.md
> although not all technically correct. "inhibitGps" is a user choice
> through the mobile app ("Use Starlink positioning exclusively") not
> system determination, but gps spoofing is indeed there. starlink could
> be authorized to decode military-grade gps signals as well?
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>
-- 
****************************************************************
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/
****************************************************************

[Starlink] Re: Starlink and Iran

[Oleg Kutkov]

Actually, a precise location is required to calculate the uplink beam.
For the downlink, it's not so critical (at least for the initial 
sky_search procedure), since the satellite beam covers the whole cell.
But the uplink beam is quite narrow, and the terminal needs to pinpoint 
the moving satellite.
 From my experiments, shifting the GPS data for more than 2km breaks the 
math and disrupts the connection. With an incorrect position, Starlink 
is stuck in NO_SCHEDULE mode.

On 1/15/26 22:07, Ulrich Speidel via Starlink wrote:
> Military-grade GPS kind of lost its exclusivity a long time ago when 
> people came up with DGPS (differential GPS), where a local reference 
> station with known position transmits a "delta" signal to the GPS 
> signal received at that location. And then of course came GLONASS & 
> Co., so there's currently about four GPS-like systems out there, and 
> most modern receivers support all. That said - these signals can all 
> be interfered with and spoofed.
>
> For Starlink, precision location isn't actually required (it's enough 
> for Dishy to know which cell it's in because that determines the 
> beams).  But GPS receiver chips are cheap and extra position accuracy 
> doesn't do any harm.
>
> On 16/01/2026 6:10 am, J Pan wrote:
>> easier to attack gps?
>> https://github.com/narimangharib/starlink-iran-gps-spoofing/blob/main/starlink-iran.md 
>>
>> although not all technically correct. "inhibitGps" is a user choice
>> through the mobile app ("Use Starlink positioning exclusively") not
>> system determination, but gps spoofing is indeed there. starlink could
>> be authorized to decode military-grade gps signals as well?
>> -- 
>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, 
>> Web.UVic.CA/~pan
>>
-- 
Best regards,
Oleg Kutkov

[Starlink] Re: Starlink and Iran

[Ulrich Speidel]

I suspect (and may be wrong there) it's not that the uplink beam is 
narrow: That would be hard to do with an antenna that's size limited by 
the need to keep it a consumer device that the customer can be expected 
to handle and install. Rather, I suspect that it's the compute overhead 
involved at the ground end when it comes to recalculating the correct 
phases for tracking the fast-moving satellite. Basically, if you had 
unlimited compute power at the Dishy, you could recompute the beam 
frequently enough to always keep the satellite at the centre of the 
beam. Instead, if you position the beam such that the satellite moves 
across it, you can wait with recomputation until the satellite is about 
to leave the beam. This means less computation, cheaper chips, and less 
power use.

That all said, a 2 km deviation isn't what I had in mind with "precision 
location" - I was thinking more of the type of deviation seen when the 
US military still applied "selective availability" to the civilian 
signal, and positions tended to be a few dozen to maybe a couple of 
hundred metres out. The 2 km more than cover this - and your 
observations actually confirm that position accuracy down to a couple of 
metres isn't needed here.

On 16/01/2026 10:47 am, Oleg Kutkov via Starlink wrote:
> Actually, a precise location is required to calculate the uplink beam.
> For the downlink, it's not so critical (at least for the initial 
> sky_search procedure), since the satellite beam covers the whole cell.
> But the uplink beam is quite narrow, and the terminal needs to 
> pinpoint the moving satellite.
> From my experiments, shifting the GPS data for more than 2km breaks 
> the math and disrupts the connection. With an incorrect position, 
> Starlink is stuck in NO_SCHEDULE mode.
>
> On 1/15/26 22:07, Ulrich Speidel via Starlink wrote:
>> Military-grade GPS kind of lost its exclusivity a long time ago when 
>> people came up with DGPS (differential GPS), where a local reference 
>> station with known position transmits a "delta" signal to the GPS 
>> signal received at that location. And then of course came GLONASS & 
>> Co., so there's currently about four GPS-like systems out there, and 
>> most modern receivers support all. That said - these signals can all 
>> be interfered with and spoofed.
>>
>> For Starlink, precision location isn't actually required (it's enough 
>> for Dishy to know which cell it's in because that determines the 
>> beams).  But GPS receiver chips are cheap and extra position accuracy 
>> doesn't do any harm.
>>
>> On 16/01/2026 6:10 am, J Pan wrote:
>>> easier to attack gps?
>>> https://github.com/narimangharib/starlink-iran-gps-spoofing/blob/main/starlink-iran.md 
>>>
>>> although not all technically correct. "inhibitGps" is a user choice
>>> through the mobile app ("Use Starlink positioning exclusively") not
>>> system determination, but gps spoofing is indeed there. starlink could
>>> be authorized to decode military-grade gps signals as well?
>>> -- 
>>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, 
>>> Web.UVic.CA/~pan
>>>
-- 
****************************************************************
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/
****************************************************************

[Starlink] Re: Starlink and Iran

[Frantisek Borsik]

Starlink Terminal GPS Spoofing/Jamming Detection in Iran:

https://github.com/narimangharib/starlink-iran-gps-spoofing/blob/main/starlink-iran.md


Shared on Twitter:
https://x.com/narimangharib/status/2011426151999193513
<https://x.com/narimangharib/status/2011426151999193513?s=46&t=cDwZQ2vjNXB5mf76dxo5Hw>



All the best,

Frank
Frantisek (Frank) Borsik

In loving memory of Dave Täht: 1965-2025
https://libreqos.io/2025/04/01/in-loving-memory-of-dave/


https://www.linkedin.com/in/frantisekborsik
Signal, Telegram, WhatsApp: +421919416714
iMessage, mobile: +420775230885
Skype: casioa5302ca
frantisek.borsik@gmail.com


On Fri, 16 Jan 2026 at 5:18 AM, Ulrich Speidel via Starlink <
starlink@lists.bufferbloat.net> wrote:

> I suspect (and may be wrong there) it's not that the uplink beam is
> narrow: That would be hard to do with an antenna that's size limited by
> the need to keep it a consumer device that the customer can be expected
> to handle and install. Rather, I suspect that it's the compute overhead
> involved at the ground end when it comes to recalculating the correct
> phases for tracking the fast-moving satellite. Basically, if you had
> unlimited compute power at the Dishy, you could recompute the beam
> frequently enough to always keep the satellite at the centre of the
> beam. Instead, if you position the beam such that the satellite moves
> across it, you can wait with recomputation until the satellite is about
> to leave the beam. This means less computation, cheaper chips, and less
> power use.
>
> That all said, a 2 km deviation isn't what I had in mind with "precision
> location" - I was thinking more of the type of deviation seen when the
> US military still applied "selective availability" to the civilian
> signal, and positions tended to be a few dozen to maybe a couple of
> hundred metres out. The 2 km more than cover this - and your
> observations actually confirm that position accuracy down to a couple of
> metres isn't needed here.
>
> On 16/01/2026 10:47 am, Oleg Kutkov via Starlink wrote:
> > Actually, a precise location is required to calculate the uplink beam.
> > For the downlink, it's not so critical (at least for the initial
> > sky_search procedure), since the satellite beam covers the whole cell.
> > But the uplink beam is quite narrow, and the terminal needs to
> > pinpoint the moving satellite.
> > From my experiments, shifting the GPS data for more than 2km breaks
> > the math and disrupts the connection. With an incorrect position,
> > Starlink is stuck in NO_SCHEDULE mode.
> >
> > On 1/15/26 22:07, Ulrich Speidel via Starlink wrote:
> >> Military-grade GPS kind of lost its exclusivity a long time ago when
> >> people came up with DGPS (differential GPS), where a local reference
> >> station with known position transmits a "delta" signal to the GPS
> >> signal received at that location. And then of course came GLONASS &
> >> Co., so there's currently about four GPS-like systems out there, and
> >> most modern receivers support all. That said - these signals can all
> >> be interfered with and spoofed.
> >>
> >> For Starlink, precision location isn't actually required (it's enough
> >> for Dishy to know which cell it's in because that determines the
> >> beams).  But GPS receiver chips are cheap and extra position accuracy
> >> doesn't do any harm.
> >>
> >> On 16/01/2026 6:10 am, J Pan wrote:
> >>> easier to attack gps?
> >>>
> https://github.com/narimangharib/starlink-iran-gps-spoofing/blob/main/starlink-iran.md
> >>>
> >>> although not all technically correct. "inhibitGps" is a user choice
> >>> through the mobile app ("Use Starlink positioning exclusively") not
> >>> system determination, but gps spoofing is indeed there. starlink could
> >>> be authorized to decode military-grade gps signals as well?
> >>> --
> >>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA,
> >>> Web.UVic.CA/~pan
> >>>
> --
> ****************************************************************
> 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/
> ****************************************************************
>
>
>
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>

[Starlink] Re: Starlink and Iran

[Inemesit Affia]

Oleg has replied with some caveats

On Fri, Jan 16, 2026, 9:01 AM Frantisek Borsik via Starlink <
starlink@lists.bufferbloat.net> wrote:

> Starlink Terminal GPS Spoofing/Jamming Detection in Iran:
>
>
> https://github.com/narimangharib/starlink-iran-gps-spoofing/blob/main/starlink-iran.md
>
>
> Shared on Twitter:
> https://x.com/narimangharib/status/2011426151999193513
> <
> https://x.com/narimangharib/status/2011426151999193513?s=46&t=cDwZQ2vjNXB5mf76dxo5Hw
> >
>
>
>
> All the best,
>
> Frank
> Frantisek (Frank) Borsik
>
> In loving memory of Dave Täht: 1965-2025
> https://libreqos.io/2025/04/01/in-loving-memory-of-dave/
>
>
> https://www.linkedin.com/in/frantisekborsik
> Signal, Telegram, WhatsApp: +421919416714
> iMessage, mobile: +420775230885
> Skype: casioa5302ca
> frantisek.borsik@gmail.com
>
>
> On Fri, 16 Jan 2026 at 5:18 AM, Ulrich Speidel via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
> > I suspect (and may be wrong there) it's not that the uplink beam is
> > narrow: That would be hard to do with an antenna that's size limited by
> > the need to keep it a consumer device that the customer can be expected
> > to handle and install. Rather, I suspect that it's the compute overhead
> > involved at the ground end when it comes to recalculating the correct
> > phases for tracking the fast-moving satellite. Basically, if you had
> > unlimited compute power at the Dishy, you could recompute the beam
> > frequently enough to always keep the satellite at the centre of the
> > beam. Instead, if you position the beam such that the satellite moves
> > across it, you can wait with recomputation until the satellite is about
> > to leave the beam. This means less computation, cheaper chips, and less
> > power use.
> >
> > That all said, a 2 km deviation isn't what I had in mind with "precision
> > location" - I was thinking more of the type of deviation seen when the
> > US military still applied "selective availability" to the civilian
> > signal, and positions tended to be a few dozen to maybe a couple of
> > hundred metres out. The 2 km more than cover this - and your
> > observations actually confirm that position accuracy down to a couple of
> > metres isn't needed here.
> >
> > On 16/01/2026 10:47 am, Oleg Kutkov via Starlink wrote:
> > > Actually, a precise location is required to calculate the uplink beam.
> > > For the downlink, it's not so critical (at least for the initial
> > > sky_search procedure), since the satellite beam covers the whole cell.
> > > But the uplink beam is quite narrow, and the terminal needs to
> > > pinpoint the moving satellite.
> > > From my experiments, shifting the GPS data for more than 2km breaks
> > > the math and disrupts the connection. With an incorrect position,
> > > Starlink is stuck in NO_SCHEDULE mode.
> > >
> > > On 1/15/26 22:07, Ulrich Speidel via Starlink wrote:
> > >> Military-grade GPS kind of lost its exclusivity a long time ago when
> > >> people came up with DGPS (differential GPS), where a local reference
> > >> station with known position transmits a "delta" signal to the GPS
> > >> signal received at that location. And then of course came GLONASS &
> > >> Co., so there's currently about four GPS-like systems out there, and
> > >> most modern receivers support all. That said - these signals can all
> > >> be interfered with and spoofed.
> > >>
> > >> For Starlink, precision location isn't actually required (it's enough
> > >> for Dishy to know which cell it's in because that determines the
> > >> beams).  But GPS receiver chips are cheap and extra position accuracy
> > >> doesn't do any harm.
> > >>
> > >> On 16/01/2026 6:10 am, J Pan wrote:
> > >>> easier to attack gps?
> > >>>
> >
> https://github.com/narimangharib/starlink-iran-gps-spoofing/blob/main/starlink-iran.md
> > >>>
> > >>> although not all technically correct. "inhibitGps" is a user choice
> > >>> through the mobile app ("Use Starlink positioning exclusively") not
> > >>> system determination, but gps spoofing is indeed there. starlink
> could
> > >>> be authorized to decode military-grade gps signals as well?
> > >>> --
> > >>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA,
> > >>> Web.UVic.CA/~pan
> > >>>
> > --
> > ****************************************************************
> > 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/
> > ****************************************************************
> >
> >
> >
> > _______________________________________________
> > Starlink mailing list -- starlink@lists.bufferbloat.net
> > To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
> >
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>