Re: [Drip] ADSB

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 12 July 2023 15:14 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: tm-rid@ietfa.amsl.com
Delivered-To: tm-rid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73A7C151701 for <tm-rid@ietfa.amsl.com>; Wed, 12 Jul 2023 08:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.632
X-Spam-Level:
X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WM9SYEFJCCgD for <tm-rid@ietfa.amsl.com>; Wed, 12 Jul 2023 08:13:59 -0700 (PDT)
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 ietfa.amsl.com (Postfix) with ESMTPS id 39700C1516F2 for <tm-rid@ietf.org>; Wed, 12 Jul 2023 08:13:54 -0700 (PDT)
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 36CFDorb013873; Wed, 12 Jul 2023 17:13:50 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DC43C203CEE; Wed, 12 Jul 2023 17:13:50 +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 CEDD3203CBE; Wed, 12 Jul 2023 17:13:50 +0200 (CEST)
Received: from [10.14.3.171] ([10.14.3.171]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 36CFDow3009400; Wed, 12 Jul 2023 17:13:50 +0200
Message-ID: <ee960fb3-e97d-85bd-8910-8b930bb9d760@gmail.com>
Date: Wed, 12 Jul 2023 17:13:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0
Content-Language: fr
To: Stu Card <stu.card@axenterprize.com>
Cc: "tm-rid@ietf.org" <tm-rid@ietf.org>
References: <6dfe8ea4-e803-5a70-c8eb-08eb3c1d4c4c@gmail.com> <2dd5fa11-d586-43e4-bd09-828c6aa77a0f@cea.fr> <MN2PR13MB4207C77AF8314327F9757A8FF831A@MN2PR13MB4207.namprd13.prod.outlook.com> <3decc87c-5b25-6349-b98f-618775dc5a57@gmail.com> <C5708075-DE36-4803-BA30-E4219E0BF1CA@tzi.org> <bc739d4f-4a03-4379-0fcb-6336f7b86ae6@labs.htt-consult.com> <33c4528e-1fb1-e329-7308-b782698208be@gmail.com> <MN2PR13MB42073DC46CDB9EFB2CF5A055F836A@MN2PR13MB4207.namprd13.prod.outlook.com> <445a964b-75b5-cf36-633e-90ce70c0814b@gmail.com> <MN2PR13MB420708D526162E9E96418914F836A@MN2PR13MB4207.namprd13.prod.outlook.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
In-Reply-To: <MN2PR13MB420708D526162E9E96418914F836A@MN2PR13MB4207.namprd13.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/mxNEq0MrvWpSNBbOleEgDfhIpsk>
Subject: Re: [Drip] ADSB
X-BeenThere: tm-rid@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Drone Remote Identification Protocol <tm-rid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tm-rid/>
List-Post: <mailto:tm-rid@ietf.org>
List-Help: <mailto:tm-rid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jul 2023 15:14:03 -0000

thanks for the clarification
I must have endeavoured in unchartered lands...

Just to clarify: I am not disputing.

I came with this thread to say that I saw ADS-B drones on flightradar.

That's about it.

Alex

Le 12/07/2023 à 16:56, Stu Card a écrit :
> The UAS RID rules are _not_ defined in this WG!
> 
> They are defined by Civil Aviation Authorities (CAAs) in each 
> jurisdiction, with coordination via the International Civil Aviation 
> Organization (ICAO).
> 
> Disputing the rules should be taken up with them, not with the DRIP WG 
> or any part of IETF.
> 
> Such rules are mentioned in DRIP docs only as background: motivation, 
> context & constraints.
> 
> Standard Means of Compliance with UAS RID rules, in turn, is mostly the 
> province of SDOs other than IETF, primarily ASTM International. Again, 
> disputing those standards should be taken up with those SDOs, not us.
> 
> Only if some reference, in DRIP docs, to the rules or external 
> standards, is factually incorrect or unclear in expression for 
> understanding by DRIP protocol implementors, is it something we should 
> be debating here.
> 
> 
> Get Outlook for Android <https://aka.ms/AAb9ysg>
> 
> ------------------------------------------------------------------------
> *From:* Alexandre Petrescu <alexandre.petrescu@gmail.com>
> *Sent:* Wednesday, July 12, 2023, 10:43
> *To:* Stu Card <stu.card@axenterprize.com>; Robert Moskowitz 
> <rgm@labs.htt-consult.com>; Carsten Bormann <cabo@tzi.org>
> *Cc:* tm-rid@ietf.org <tm-rid@ietf.org>
> *Subject:* Re: [Drip] ADSB
> 
> 
> 
> Le 12/07/2023 à 16:00, Stu Card a écrit :
>> Very short answers (all for which I have time):
>> 
>> The rules for RID are based not primarily on RF considerations, but 
>> on aviation considerations.
> 
> hmmm... it's a principle that is reasonable and that could be debated.
> 
> One will excuse me for not knowing precisely what are the RID rules.
> The RID rules are defined in this WG and I will need to look at them.
> 
> If I look at them, one day, I will look at them from this perspective:
> 
> For example, when RID rules say 'altitude' they should say 'altitude
> expressed in meters and not in feet as is currently the inherited case
> from WWII development of aviation'.
> 
> This kind of text could be of enormous help to implementers: they simply
> would need to call less functions(), because less need of conversions.
> 
> It is the same when RID rules say 'heading' or 'speed', or when we talk
> about airport track orientation.  It should be made easy to implementer
> to compare a heading value in a 'heading' of a UAS to that of a track.
> One should come up with a single common way of expressing track
> orientation, compatible to that of RID rules, instead of several and
> incompatible, as is the case in current air flight industry.  It is
> because if one does that (interoperable defs of headings) then the
> programmer has an easier task.
> 
> Also, about RID rules: they should say that when ASTM wants to send
> position and heading they should send the NMEA statements, without
> conversion.
> 
> Until then, if we can not do that, we can also have a human listening to
> the radio airport and maneouvering locally or from a distance, using an
> innombrable number of calculators and conversions, after having learned
> tomes of manuals about how to fly things.  It is basically easier.
> 
>> 
>> Crewed aircraft _mostly_ fly above 500 feet, except during takeoff 
>> and landing.
> 
> I always had problems with this term 'crewed' aircraft.  I noticed it
> also in the TVR WG, in its reverse form 'uncrewed' aircraft.
> 
> But in reality there can be uncrewed crewed aircrafts too (Unmanned Air
> Mobility device, a flying taxi, does carry a couple of persons on board
> - 'crew?', yet none of them actually drives the UAM - they just signed
> the insurance agreement).  An uncrewed aircraft is still crewed by the
> fact that a (group of) persons on the ground is its crew (drone Reaper
> is such).  There can also be these devices that are not crewed, are not
> continuously driven from a ground by a crew, yet there are very many
> eyes of people loooking at where it is going to - they're
> pre-programmed.  These would be the true 'uncrew' aircraft even though
> there are many crews simply looking at them.  They fly at more altitudes
> than 500 feet.
> 
> This is why I am not sure how to use this term 'crewed aircraft'.
> 
> But I think you meant a 200 passenger aircraft like a regular airline
> flight from a city to another.  Even that can be automated (crewless?) soon.
> 
>> Small uncrewed aircraft _mostly_ fly at much lower 
>> altitudes, as they are flown largely not to get from one place to 
>> another, but for photographing or otherwise sensing things on the 
>> ground (or for recreation).
> 
> BEcause of this term 'crew' I can not say whether I agree or not with you.
> 
> Instinctively, I'd say that there are so many other flying aircraft that
> it is hard to say so easily at which altitudes are they allowed or not,
> simply based on that 'crewed' qualifier.
> 
> I think the point of view of 'crewed' vs 'uncrewed' is limited in
> itself, leading to potentially missing some aspects.
> 
>> The FAA has established an upper limit
>> of 400 feet AGL for small uncrewed aircraft flying under their rule 
>> appropriate for most such, to provide 100 feet of vertical
>> separation from these small UAS and where the crewed aircraft
>> _mostly_ fly.
> 
> I will not oppose - maybe it is sufficient for them.
> 
> If I were to be picky, I'd say that the notion of 'AGL' itself can be
> subject to debate (there are several sea levels in this world and
> moreover they change as we speak) and if one asks why then I reply that
> if one would like to put NMEA statements in ASTM messages for the goal
> of avoiding conversions then one might be facing such aspects of
> precisely what is a sea level.
> 
> But I will not go to the respective SDO, so I leave it there.  I agree
> they set limits where they need them.
> 
>> WRT units: yes it is a mess; no the EU does not use precisely the 
>> metric equivalents of feet etc. in their rules; note my original 
>> message said "EU rules are similar" not "EU rules are the same
>> except for translation of metric units".
> 
> I agree, you did not say that.
> 
>> IETF does not get to write rules for aviation, therefore neither
>> does IETF get to write rules for aviation communications; we can
>> only provide technical standards for interoperable network protocols
>> that _enhance_ those communications.
> 
> It's a good thing, because enhancing communications is always good.
> 
> Alex
> 
>> 
>> -----Original Message----- From: Alexandre Petrescu 
>> <alexandre.petrescu@gmail.com> Sent: Wednesday, July 12, 2023 9:45 AM
>> To: Robert Moskowitz <rgm@labs.htt-consult.com>; Carsten Bormann 
>> <cabo@tzi.org> Cc: Stu Card <stu.card@axenterprize.com>; 
>> tm-rid@ietf.org Subject: Re: [Drip] ADSB
>> 
>> 
>> 
>> Le 12/07/2023 à 13:56, Robert Moskowitz a écrit :
>>> 
>>> 
>>> On 7/12/23 06:45, Carsten Bormann wrote:
>>>> On 2023-07-12, at 11:52, Alexandre Petrescu 
>>>> <alexandre.petrescu@gmail.com> wrote:
>>>>> why not 400m
>>>> This is not a domain where we get to invent boundaries.
>>>> 
>>>> (Also, generally speaking, of course we should have a strong
>>>> bias to using SI units, but in a domain where regulation is
>>>> widely based on furlongs per fortnight, we’ll have to adapt.)
>>> 
>>> And anyway it would be 125M to be a bit more than the Imperial 
>>> 400'.
>> 
>> True.
>> 
>> And it obviously begs the question whether in Europe they also have 
>> the same limit of 400' equivalent in meters.  I strongly doubt that 
>> an EU document would talk about a limit of precisely 121.92 meters 
>> just because of being converted to the easy to grasp 400 feet.
>> 
>> At that point we talk about devices that might be different in an EU 
>> market than in an US market.
>> 
>> What is the EU altitude limit for numerous drone aircraft to be 
>> considered flying very low, so numerous and so low such as to be 
>> forbidden to carry ADS-B equipment (or turn it off at lower than
>> that altitude if it carries one)?
>> 
>>> Why 400'?
>>> 
>>> I think it was to keep general aviation some reasonable distance 
>>> above people on the ground.  As the ceiling for UA that is a 
>>> consequence.
>> 
>> You see, I think there is an error.
>> 
>> 400 feet might be a good limit in terms of separation of people and 
>> objects above their heads, but it is certainly not any limit in
>> terms of radio communication.
>> 
>> If there is to be a radio communication limit (use or not use ADS-B) 
>> it should be based on the power levels it uses and the guarantees of 
>> range. In WiFi, bluetooth and 2G..5G that's how they separate.
>> 
>> For example, an 5G-carrying UAS would be limited to 450meter
>> altitude because that is how high the ground 5G oriented towards
>> ground reaches high.
>> 
>> A bluetooth-carrying UAS (and not carrying ADS-B) would be limited to
>> 100 meter altitude because that is how high a bluetooth device is 
>> allowed to emit, by bluetooth regulation.
>> 
>>> "They can't go any lower, you can't go any higher."
>> 
>> Strange.  Many devices, especially those who plane or glide like 
>> these UAS drones, and helicopters too, will stay stable at very many 
>> low altitudes.  Their power systems - more and more performing, 
>> allows for that.
>> 
>> I very well see a helicopter stable 100meter above the ground, and 
>> surely it carries an ADS-B device, if not several of them.
>> 
>>> 
>>> It is called boundaries to keep unequal players apart.
>>> 
>>> One of the interesting debates in this is that the 400' floor is to
>>> ground obstacles like radio towers.  Thus since big birds have to
>>> stay 400' from that 700' radio tower down the block, you can take
>>> your UA up to 1100' right next to it...  Or so some claim.
>> 
>> Right!
>> 
>> RAdio towers, or radio towers with even higher anti-flash 
>> ('paratonnerre', fr.) on them?  That adds some 10 meter to the 
>> picture, to which an UAS drone would need to pay attention, just
>> like helicopters need to care about power lines above ground too.
>> 
>>> 
>>> And speaking of Imperial vs Metric...
>>> 
>>> Civil aviation separation is 1000'.
>>> 
>>> This has already caused incidents where a lesser  Metric distance 
>>> was used by one aircraft against one using the greater separation 
>>> of Imperial.
>>> 
>>> Fun!
>>> 
>>> Not.
>> 
>> I agree.
>> 
>> Alex
>> 
>>> 
>>> Bob
>>> 
>