Video wird geladen...

Video konnte nicht geladen werden

Zur Startseite

Welcome to Physics with CatSE. We’ll be using 4 methods not known to analysts (Such as TMF associates.) covering the D2D space race: -Math. -Physics. -Phased Array Antenna Simulator tools. & -Logic. To answer questions: Does size matter? And if so how? Pointy =scary? 🧶🐈‍⬛ 1/

24,965 Aufrufe • vor 1 Monat •via X (Twitter)

28 Kommentare

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

Lets get a couple of benchmarks up. This is a Starlink v1 DTC satellite phased array. It’s on orbit. I counted the antenna elements. They are 1600 arranged 40x40. The lattice spacing is half wavelength ~3 inches. 2/

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

An array of 40 elements would be roughly 3.0 – 3.14 meters long, depending on whether it is optimized for the uplink or downlink frequency of PCS-G block. The way elements are arranged they stack a bit more narrow one way. And we can simulate the Starlink DTC beam. 3/

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

I used the full array to generate this edge beam at 25.9 degrees look angle. This corresponds to 58.4 degrees scan angle, Theta. If we add a circle for where earth is in yellow and a red circle for ten degree cutoff we see a lot of sidelobes hitting where emissions are prohibited.🚫 4/

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

We add advanced $ASTS proprietary and patented weighting AKA tapering on Starlinks v1, as a thought experiment. This requires controlling 1600 attenuators per beam. AND $ASTS patent. Such patents are more of a constrain than launch. If you use logic not feelings in analysis. 5/

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

The result of tapering the edge beam on Starlink v1 DTC was as could be expected a: Reduction of sidelobes. Reduction of main beam and grating lobe directivity. Gain dropped 33.85-31.40 =2,45 dB Where Starlink is at that drop cuts the link. So they’re not able to use ASTs patent would they ve allowed it. And will opt to spatially spam the planet with sidelobes instead. (Note the individual element gain of ~5dB is to be added to each to get full gain of the system.) 6/

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

Now lets do an edge beam of $ASTS BlueBird Block3. (Launching in 2027) They span the same spectrum bandwidth as Starlink DTC and is comparable in things like element spacing and frequency. But they are larger. 160x192 elements =30,720 12.88x15.456 m (199 sqm) 7/

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

We’ll apply a simple Hamming Taper. What it does is that it attenuates edge antennas to dampen sidelobes on wide scanning angles. It’s a RADAR technique that $ASTS miraculously got patented for communications applications. And we’re using the same Theta, scan angle as tge Starlink example. 58.4 degrees. 9/

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

This is the resulting -white knight -beam. I put Starlink -Black Ships - DTC beam next to it in two versions. One as is with sidelobes, and the other with hypothetical taper and blunter beam. Notice that $ASTS beam is ~10.5 dB more pointy. 10x more pointy. (TBC, dinner time) 10/

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

Let’s compare 72 $ASTS Block3 2GHz beams to 18 Starlink v1 DTC 2GHz beams. You might notice a smear of sidelobes in the Starlink plot. That type of self degradation creating high noise in its ovn bands is the reason Starlink never launched more V1 mini DTC. They immediately run into law of diminishing returns. And can not scale their current system. 🐾

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

And now physichs/math: The key performance metric of an direct to device satellite system is per Area Spectral Efficiency, ASE. We derive it from Shannons law of capacity (throughput). Rearrange that to show an efficiency metric (throuhput per bandwidth), known as Spectral Efficiency, SE Then lastly for Area spectral efficiency divide it with Area served.

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

And so on a single satellite to satellite comparison you get an larger increase in efficiency by increasing area. An outsized efficiency gain of fewer but larger arrays. In other words larger sats is better than many sats. That’s just RF physics!

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

Now lets examine mathematical how these components scale when increasing Antenna Area 🅰️ SNR, Signal to Noise ratio, increases with Gain, which increases proportional to 🅰️ ASE ∝ SNR ∝ 🅰️ 👍 n, Number of antennas on uncorrelated signal paths increases also proportional to 🅰️ as does number of beams per sat. ASE ∝ n ∝ 🅰️ 👍 And 1/Coverage Area means ASE also increases proportional to ASE ∝ 1/A We will not change coverage Area, although there is some positive correlation also here.

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

We can also compare the 19x larger satellites versus 19x more numerous satellites in an systems level equal total acerage of antenna comparison. Spoiler: Larger satellites win. And we haven’t even taken the sidelobes and grating lobes into account yet.

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

Here are 18 Starlink beams.

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

And so we get this. ASE on an individual satellite level scales proportional to A log A. And the magnitude of the improvement by simply going from 40x40 to ~175x175 an 19x aperture area increase thus corresponds to an ASE, efficiency, increase of 64 to 44x depending on your initial SNR assumption. The base 19x from the n factor and rest from the log SNR factor.

Profilbild von Fiiasco
Fiiascovor 1 Monat

Great and interesting explanation. Thanks for so much input, so if I understand it in simple terms, due to the fact that the area is bigger the sidelobe is less of an effect resulting in higher gain (more pointy) and thus more SE?! Or am I missing the point completely?

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

You got that right. And you now have more understanding of these things than the most often quoted analyst in articles on AST the last 6 years.

Profilbild von Fiiasco
Fiiascovor 1 Monat

Thanks Catse, I have understood all of the derivative from a mathematical POV and the physics how you explained. But what I did not understand is, why does v1 behave this way? Why does it cause these patterns and BB dont, even though the delta dB seem alike? Or am I wrong?

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

Delta dB differs. Because of size/area mainnly and in two ways. 1. Directly causing larger directivity of the main beam 2. Indirectly because AST has lots of area they can use some of it despite a certain directivity penalty to taper their array (attenuate edge elements) causing a disproportionate and much larger reduction in the sidelobes than in the very directive main beam. Which still remains sharp enough while the sidelobes dive down to natural background levels.

Profilbild von Fiiasco
Fiiascovor 1 Monat

Hey CatSe, don't want to spam you, but I figured it out. Due to their size, as you said, the main beam in comparison to theta=/0 is way bigger allowing for more precise signals. While with starlink their 14dB noisefloor still "echos" in other areas around theta=0. = interference

Profilbild von Fiiasco
Fiiascovor 1 Monat

Thanks for everything.

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

Here are all 8 edge beams activated simultaneously.

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

Now lets adjust phi to illustrate the sidelobe and grating lobe problem. Here are 4 different beams pointing in phi increments of 20 degrees different azimuth. Like pointing east to north-north-east.

Profilbild von Kevin Coulton 🅰️
Kevin Coulton 🅰️vor 1 Monat

$ASTS Hi CatSE, I just "attended" your Physics class. While I am a practicing engineer (civil engineer...with a focus on water and dirt) and understood some of the RF physics you presented, I immediately latched on to your image below and the dirt-like substance spewing from Elon's vehicle (is that a "tractor" beam...? :D). To me, this image says it all. Thanks for sharing this information!

Profilbild von 🅰️lways high beta and seeking for 🅰️lpha
🅰️lways high beta and seeking for 🅰️lphavor 1 Monat

Forget it. He never got a pass Euclidean geometry.

Profilbild von C🅰️tSE
C🅰️tSEvor 1 Monat

Four more for north to nort-west. See all these sidelobes? They spam bad radio signals.

Profilbild von Michael S
Michael Svor 1 Monat

I don't know how anyone could take Tim or Stu's "expertise" opinion on anything, when clearly the true expertise is right here with @CatSE___ApeX___ . All those guys do is spew FUD and bullsh!t opinions.

Profilbild von Skinner64
Skinner64vor 1 Monat

@Defiantclient2 Hi CatSE. Great analysis. I’m not the best at digesting this level of math, sorry if this question is already answered but how many simultaneous calls can each AST satellite handle?

Ähnliche Videos

Why the character movement in my custom game engine felt janky and how I fixed it. In a game engine, most often, a character moves using the physics engine. Meaning, the player is not just a coordinate in space but a physical body. It has velocity, it handles collisions, and it interacts with the world. Now, as you might know, physics engines need stability. If you run them at variable framerates, things start breaking. Objects phase through walls or fly off into space because the math becomes unpredictable. This is why most game engines lock their physics loop to a 60Hz fixed rate. But here’s the problem: If you have a high-end system, you don't want to limit it at 60 FPS. That's a waste of good hardware. Now, that said, if the GPU is rendering at 144 FPS but the player's position (physics driven) only updates 60 times a second, it creates a micro-stutter that ruins the "smooth" feel of the game. A good way to fix this is to treat the character as two separate things: 1. The Physics Body (Invisible part): This is the "real" character. It lives in the 60Hz physics world, it moves the player and handles collisions. 2. The Visual Model and Camera (Visible part): This is what the player actually sees. It doesn't care about collisions, its only job is to look nice and smooth at whatever framerate the GPU is pushing. Once you have this separation, you can use interpolation to keep them in sync. Every time the physics clock ticks, you save the previous position of the invisible body before moving it to the new one. Between those ticks, calculate how far we are between the last physics update and the next one. By using this to drive the visible parts of the game, the stutters disappear. The physics loop stays fixed behind the scenes, while the visuals slide smoothly between the snapshots. Example: - Right after a tick: blend_weight= 0.0 (The visual model stays at the old physics position). - Halfway to the next: blend_weight= 0.5 (The visual model slides to the middle point). - Just before the next: blend_weight= 0.9 (The visual model is almost at the new physics position). Pro-Tip A critical mistake I made initially, and one many devs make, is parenting the camera and visible parts directly to the player body. If you do this, the camera inherits the discrete 60Hz physics movement by default. In that setup, interpolation won't work because the camera is "stuck" to the physics clock. For this fix to work you must decouple the camera and visuals from the body and move them separately. Player movement processing in Detis Engine: - fixed_process: Physics runs at 60Hz. Handles collisions and raw movement. - process: Variable rate. Mainly used for player input caching in the player case. - late_process: Variable rate. Handles interpolated camera movement after physics and everything else is done being processed. - render. Submits the final interpolated transforms to the GPU. The test environment in the video is running on an old 2070-based laptop. Hopefully the video compression won't introduce any stutter... I’m sharing this in hopes it helps a fellow dev. Cheers.

Ioannis Koukourakis

48,703 Aufrufe • vor 8 Monaten