[Starlink] starlink extensions over uk
Ulrich Speidel
u.speidel at auckland.ac.nz
Wed Jul 27 09:37:09 EDT 2022
On 27/07/2022 1:35 am, Mike Puchol via Starlink wrote:
>
> The interference is directly in-band, as the Ku and Ka bands are used
> both by satellite TV, GEO data systems, and Starlink. Thus, if a
> Starlink satellite in-line between a satellite TV customer and the GEO
> satellite, the satellite TV customer would experience considerable
> interference. This is why Starlink satellites, gateways, or user
> terminals cannot transmit anywhere between 10º above and 10º below the
> GSO arc (18º previously).
Hang on a second - there's a terminology issue here relating to the term
"band". "Ku band" refers to frequencies between (roughly) 12-18 GHz and
"Ka band" to frequencies between about 26-40 GHz. "Out-of-band
interference" refers to signals emanating from a transmitter that are
outside its intended signal bandwidth - and that signal bandwidth is
normally a lot smaller than the bandwidth of the Ku or Ka band - unless
we're talking UWB applications here, and we're not.
A Starlink satellite or ground station will only ever transmit (wanted
signal) within a small sub-band within these bands. For example, in NZ,
Starlink only holds licenses for five 500 MHz sub-bands of Ka between
27.5 GHz and 30 GHz, and half a dozen 250 MHz subbands of the Ku band.
So we can safely assume that any transmissions from Starlink ground
stations will take place within these limits. We can also safely assume
that an individual transmission between a ground station and a single
satellite will occupy at most one of these sub-bands, and for Dishys
it's likely to be a lot less than that.
Any GEO sat listening to that sub-band from behind the transmission's
target Starlink bird would indeed experience in-band interference. Any
GEO sat listening to other sub-bands of Ka or Ku that the one used for
uplink may also experience interference, but in this case it's out of
band because it isn't within the sub-band that the Starlink ground
station transmits in.
Normally:
* A transmitter will be designed so as to minimise emissions outside
its core wanted signal spectrum in the sub-band / channel in which
it's operating. Why? Because power outside that core bandwidth is
wasted, and can be a source of interference to others. This is
achieved with a band pass filter around the transmit frequency that
is designed to let the wanted signal pass and hold anything else back.
* Similarly, a receiver listening to a signal on a different frequency
will use a band pass filter to keep signals outside that wanted
frequency range out.
Think of ideal signals as being vehicles on a road that stick to their
own lane so they don't bump into each other. So where's the problem? The
problem is twofold: Firstly, receivers are designed to handle very weak
signals and amplify them to the point where they "mean something" if
there's any meaning to be had in them. Secondly, those band pass filters
aren't perfect. They suppress signals in the unwanted part of by a
decent amount but not completely. How "decent" an amount depends on the
construction of the band pass filter, and that in turn depends on size,
precision, material, number of filter elements, resistive losses etc. It
also depends on how far that frequency of interest that you want to have
suppressed is from the band that that band pass filter will let pass.
The further the better.
For the GHz microwave spectrum in which the Ku and Ka bands lie, band
pass filters are essentially just appropriately shaped pieces of metal.
Size isn't so much the issue as wavelengths are very short, but
precision and material / resistive losses (skin effect) are. There's
only so much gold you want to put into a Dishy and gold only gets you
that far.
So in order to interfere with a GEO sat receiver, a Starlink ground
terminal will have to either:
1) Produce a spurious signal in an unwanted part of the spectrum (not to
be confused with antenna side lobes, that's a different type of unwanted
signal - any part of the spectrum but wrong direction of propagation and
normally at a much lower power level). In any decent transmitter with
band pass filter, this is likely to be several orders of magnitude below
the wanted signal. That unwanted signal has to propagate along the much
longer path to the GEO sat, where it is subject to path loss. It then
has to arrive at the GEO sat with sufficient signal strength in order to
raise the noise + interference level at the GEO sat's receiver to a
point where the signal-to-noise-plus-interference ratio at the receiver
falls below the minimum required for that sat's mission.
2) Have its wanted signal communicate well beyond its intended target
(extra path loss again) to have it suppressed to a good extent by the
band pass filter at the GEO sat receiver that is there to keep out of
band signals out. If the residual signal from the Starlink terminal is
still strong enough to raise the noise + interference floor at the
receiver enough to lower the signal-to-noise-plus-interference ratio at
the GEO sat, then again we have a problem.
Sadly, both are possible - however as I've argued, it's probably less of
an issue with Starlink than with other types of NGSO services.
Side lobes are usually orders of magnitude below the main lobe, so tend
to be less of an issue than the main lobe as they project a much lower
signal to start with. Plus these signals aren't correlated when coming
from different transmitters, so it's a matter of "powers add" not
"amplitudes add", and powers drop by one over distance squared, so...
I'm not sure how seriously one should take these complaints.
In the RF world, not everything is as it seems. When they ask you to
turn your mobile (cell) off on the plane, the usual grounds proffered
are some nebulous claims of interference with navigational systems -
which hasn't actually stopped people from putting base stations into
airliners, although their means of navigation haven't changed all that
much. Plus, a lot of planes fly with active cellphones on board. The
reason why airlines don't want this is because the mobile networks
aren't designed for handovers at several hundred knots from 30,000 feet,
where a phone can keep a large number of base stations very busy with
handovers. So the mobile operators require airlines to minimise this
nuisance - and that's why they play on your fear of flying, and why it's
become an accepted part of flying culture that your plane might crash if
you leave your phone on... ;-)
>
> This presentation on the subject was shared by a friend earlier, it is
> a really good read on the topic:
> https://www.itu.int/en/ITU-D/Regional-Presence/AsiaPacific/Documents/Events/2017/Aug-ISS2017/PAPER_Workshop_S3_Timur.pdf
> <https://www.itu.int/en/ITU-D/Regional-Presence/AsiaPacific/Documents/Events/2017/Aug-ISS2017/PAPER_Workshop_S3_Timur.pdf>
>
> Phased array antennas are notoriously prone to generating considerable
> sidelobes, unlike e.g. a Cassegrain dish. A good article on these (and
> mitigations) can be found here:
> https://www.mwrf.com/technologies/systems/article/21143497/analog-devices-phasedarray-antenna-patterns-part-6sidelobes-and-tapering
> <https://www.mwrf.com/technologies/systems/article/21143497/analog-devices-phasedarray-antenna-patterns-part-6sidelobes-and-tapering>
>
> These sidelobes contribute to the interference, and have been a major
> source of complaints by the likes of Viasat and others - whereby they
> claim SpaceX doesn’t consider the additive effects of sidelobes from
> dozens or hundreds of ESAs on satellites and terminals, against a
> single victim earth station or satellite.
>
> Best,
>
> Mike
> On Jul 26, 2022, 16:10 +0300, Ulrich Speidel via Starlink
> <starlink at lists.bufferbloat.net>, wrote:
>>
>> So then the difference really is just in the GSO protection settings
>> I guess.
>>
>> The GSO protection is - to an extent - also patch protection. After
>> all - who'd need satellite TV if everyone could watch the same TV via
>> LEOs? But consider that:
>>
>> * Interference to GEO sats from Starlink & Co. is out of band. I'm
>> not sure what the out-of-band emissions profiles of dishys are,
>> but I'd imagine we'd be looking at the usual few dozen dB below peak.
>> * Distance to GSO is around 64 times (2^6) larger than to
>> Starlink's orbits - GEO sats see around 1/4000th ((2^6)^-2) of
>> the power from a ground station that the Starlink satellite in
>> front of it sees. That's 36 dB in extra separation.
>> * Dishy is comparatively small in cross-section, and that severely
>> limits its gain. Most serious GEO uplink applications that I'm
>> aware of use dishes more like 8 times dishy's cross section.
>> That's another 9 dB or so in separation between a Starlink dishy
>> signal and signal directed specifically at a GEO sat just from
>> the overall size. Uplinks from gateways are likely to be much
>> more of an issue (always on and probably higher power as well as
>> ~6 dB higher antenna gain judging from the photos I've seen), but
>> then again these point away from the GSO when serving birds
>> further north.
>> * My understanding (correct me if you think I'm wrong here): It's
>> also possible that Dishy's nature as a phased array helps here.
>> Why? Out-of-band interference results from intermodulation and
>> other unwanted emissions from the power amplifiers (PA) of
>> transmitters. Where these are fed into a dish from a single PA,
>> their amplitudes get amplified by the gain of the dish. Now say
>> we're trying to replace that dish by an array with N antennas and
>> N associated PAs that feed at the appropriate phase. Then each
>> element (individual PA with associated antenna) needs to
>> contribute P/N of the total transmit power P of the big PA &
>> dish. Now remember that power is proportional to the square of
>> the amplitude. As long as the wanted signal components from the
>> PA are correlated - and they have to be for the phased array to
>> work - their N amplitudes add up, meaning the total output power
>> of the wanted signal across all elements is proportional to N^2.
>> So each element only needs to contribute an amplitude
>> proportional to 1/N in order to produce the wanted output at the
>> correct power. However, now each PA produces its own dirt signal.
>> But unlike the wanted signal, these unwanted signals aren't
>> necessarily all correlated between the elements. As a result, the
>> amplitudes of the unwanted signals from the PAs will partially
>> cancel out as the signal combines into the beam that is being
>> formed. So only the powers of these uncorrelated unwanted signals
>> add up, but their amplitudes don't, meaning we now have an
>> unwanted signal power that is proportional only to N rather than
>> N^2, resulting in a higher ratio of wanted signal to unwanted
>> signal. Again that'd help a lot with separation in an array with
>> lots of elements and associated PAs. That said, published
>> research into the unwanted emissions of phased arrays is still a
>> bit in its infancy, and I can't profess to understand enough
>> about Dishy's innards or the level of correlation between
>> unwanted emissions in the array, but I'd consider it possible
>> that this allows for some relaxation on the GSO protection
>> parameters when it comes to Starlink.
>>
>> On 26/07/2022 9:06 am, Mike Puchol via Starlink wrote:
>>> Your calculations are “Back of the Envelope Approved” :-)
>>>
>>> My simulator can be found at https://starlink.sx
>>> <https://starlink.sx>
>>> and runs on your browser (desktop only). I have just released
>>> v1.10.6, which adds a slider for setting the GSO protection. This is
>>> the difference in Sweden from 18º (as used until recently) versus
>>> 10º (as found in recent ITU filings for STEAM-1B):
>>>
>>> <18_vs_10_GSO.png>
>>>
>>> Minimum elevation in both cases is 25º, so that variable is unchanged.
>>>
>>> Best,
>>>
>>> Mike
>>> On Jul 25, 2022, 11:35 +0300, Ulrich Speidel via Starlink
>>> <starlink at lists.bufferbloat.net>, wrote:
>>>>
>>>> I haven't got Mike's nice software but I got snail mail today, so
>>>> let's try the back of one of the envelopes.
>>>>
>>>> 53 degrees north (where the existing constellation tops out) is
>>>> roughly the latitude of Nottingham or Stoke-on-Trent. Note that
>>>> this is also the latitude with the largest number of birds per km
>>>> (or mile, if you so prefer) of parallel. They sit almost cheek to
>>>> jowl there.
>>>>
>>>> Now the northern tip of the UK's main islands is at around 59
>>>> degrees north - that's six degrees more. One degree of latitude is
>>>> roughly equivalent to 10,000 km / 90 degrees = 111 km, so we're
>>>> talking around a devilish 666 km to the north of Nottingham here as
>>>> the crow flies.
>>>>
>>>> Lets assume Dishy points itself due south at 59 degrees. The birds
>>>> are at about 550 km. So doing a flat earth approximation for the
>>>> moment, we're having to point at a satellite 550 km up from 660 km
>>>> away - that gives an elevation of about 40 degrees
>>>> (=arctan(550/660)). Ballpark. Now reduce that by the 6 degrees of
>>>> difference to account for the curvature of the earth and we still
>>>> have around 34 degrees, allowing for a bit of leeway either side if
>>>> the closest bird isn't actually due south but a bit to the east or
>>>> west. Again, ballpark, but we're nowhere near 25 degrees yet.
>>>>
>>>> So I'd say that should cover it nicely? Where does my envelope err?
>>>> GEO arc protection aside for the moment, of course. And of course
>>>> just because Starlink offers you service doesn't mean that it's
>>>> actually continuous.
>>>>
>>>> On 25/07/2022 8:59 am, Dave Taht via Starlink wrote:
>>>>> For those of you that don't follow mike's twitter feed...
>>>>>
>>>>> https://twitter.com/mikepuchol/status/1551288485713149952
>>>>> <https://twitter.com/mikepuchol/status/1551288485713149952>
>>>>>
>>>>> --
>>>>> FQ World Domination pending:
>>>>> https://blog.cerowrt.org/post/state_of_fq_codel/
>>>>> <https://blog.cerowrt.org/post/state_of_fq_codel>
>>>>> Dave Täht CEO, TekLibre, LLC
>>>>> _______________________________________________
>>>>> Starlink mailing list
>>>>> Starlink at lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>> <https://lists.bufferbloat.net/listinfo/starlink>
>>>> --
>>>> ****************************************************************
>>>> Dr. Ulrich Speidel
>>>>
>>>> School of Computer Science
>>>>
>>>> Room 303S.594 (City Campus)
>>>>
>>>> The University of Auckland
>>>> u.speidel at auckland.ac.nz
>>>> http://www.cs.auckland.ac.nz/~ulrich/
>>>> ****************************************************************
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink at lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>> <https://lists.bufferbloat.net/listinfo/starlink>
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>>
>> --
>> ****************************************************************
>> Dr. Ulrich Speidel
>>
>> School of Computer Science
>>
>> Room 303S.594 (City Campus)
>>
>> The University of Auckland
>> u.speidel at auckland.ac.nz
>> http://www.cs.auckland.ac.nz/~ulrich/
>> ****************************************************************
>>
>>
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>> <https://lists.bufferbloat.net/listinfo/starlink>
>
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
--
****************************************************************
Dr. Ulrich Speidel
School of Computer Science
Room 303S.594 (City Campus)
The University of Auckland
u.speidel at auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/private/starlink/attachments/20220728/b8fe3347/attachment-0001.html>
More information about the Starlink
mailing list