From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D75173B29E for ; Sun, 17 Sep 2023 13:09:19 -0400 (EDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 38HH9IjW044305 for ; Sun, 17 Sep 2023 19:09:18 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5A4F0200C21 for ; Sun, 17 Sep 2023 19:09:18 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4EC86200BED for ; Sun, 17 Sep 2023 19:09:18 +0200 (CEST) Received: from [10.14.0.60] ([10.14.0.60]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 38HH9I4Q000812 for ; Sun, 17 Sep 2023 19:09:18 +0200 Message-ID: <25dba59e-9661-419a-bc20-1ec3d3177c14@gmail.com> Date: Sun, 17 Sep 2023 19:09:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: fr To: starlink@lists.bufferbloat.net References: <2d05e701-7556-8ae4-122c-e2f2d23feff2@gmail.com> <4o116qp9-6108-91r8-pn91-o37o6629npqo@ynat.uz> <2012b68c-2e15-4b5c-b36b-3b1d7eff12b4@gmail.com> From: Alexandre Petrescu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2023 17:09:20 -0000 Le 15/09/2023 à 17:18, Ulrich Speidel via Starlink a écrit : > > > On 15/09/2023 11:29 pm, Alexandre Petrescu via Starlink wrote: >> >> I must say that I dont know whether the original 'DISHY' is simply a >> dish antenna with an analog amplifier and maybe some mechanical motor >> steering, or whether DISHY includes a computer to execute some protocol, >> some algorithm. > > It's a phased array, not a dish, even if it looks like one. It > consists of 100's of fingernail-sized antenna elements that: > > * during transmissions, have an individual phase delay added to the > signal transmitted from that element, in order to permit > transmission of the combined signal from all elements into a > particular direction. > * during reception, have an individual phase delay added to the > signal collected by that element, before the signals are added to > obtain the combined received signal. This allows reception from a > particular direction. > > Dishy's main direction of transmission / reception is therefore not > its surface normal - this simply points to the area of the sky where > Dishy expects to see most satellites (a function of geographical > latitude and constellation design - essentially straight up in the > tropics, and elsewhere in the direction of the 53rd parallel, which > corresponds to the predominant orbital inclination in the Starlink > fleet). The actual tracking is then done with the phased array without > mechanical movement by Dishy. > Thanks for the description.  It is an advanced and interesting antenna behaviour for a consumer product.  It is good the mechanical motor is replaced with phasing. More advanced phasing is probably used in their antenna version for automobiles, but might be the same principles. Then, for ships, where more 3D-imensional like movements exist, replacing big motors with phasing can represent significant gains in terms of space occupied. > From what I've seen, Dishy seems to consume more power on receive than > on transmit - that's if you actually download stuff. This is somewhat > counter-intuitive if you're used to putting link budgets together. But > I'd attribute that to a higher degree of digital signal processing > required on the receive and demodulation path. > It is interesting it consumes more on receive than on transmit. Thanks. There was a pointer here pointing to an ETSI document about what might be a sort of certification (access to medium to not disturb the others).  In it, it seems a different freq is used for transmit than for receive. (12 vs 14GHz, or so, or vice-versa). The difference in frquency might also be a factor (in addition to the dsp calculus you mention) in differentiating the consumption up vs download.  I'd expect working with higher freuencies to require more energy.  But I am not sure an ETSI document can be for US starlink end user device. Alex > -- > **************************************************************** > 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 > https://lists.bufferbloat.net/listinfo/starlink