Re: [Drip] ADSB

Stephan Wenger <stewe@stewe.org> Thu, 13 July 2023 08:44 UTC

Return-Path: <stewe@stewe.org>
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 E92F9C15106F for <tm-rid@ietfa.amsl.com>; Thu, 13 Jul 2023 01:44:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steweorg.onmicrosoft.com
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 NtfJNdSWE0-d for <tm-rid@ietfa.amsl.com>; Thu, 13 Jul 2023 01:44:34 -0700 (PDT)
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2104.outbound.protection.outlook.com [40.107.93.104]) (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 AFB6FC13AE3D for <tm-rid@ietf.org>; Thu, 13 Jul 2023 01:44:32 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n2y0K12vcUTxNnY9M1p7YD4O2Syfenn79heG0OjYYpTpEA1gho4JWlWzNbiEdTKwlx1PH64nD7cZ1GQA6ZBTQWnYP+NtpK5WxBEZHHcyIqXwt8M7KS92tzVIyTedV9n8IR0ZUn/guoqQS2EGkl7lmWHduh6t2LQozkIn/nkWgQaZEqCnpBKRAOE59iDXRkImvoxk5y85VyQwjwDGtYKHAolEi92NvTCdNzLkH6oRO7+m1pY8FbsQQ1UbXUXxjQKpBP61KKIH6DVwt308JTGTYAs4hXTdxO5Q/NixmEhRVcrDm4697HVzpoRu1gaROGTFkRPUN2mXbypcSgfJDGMvDw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iigwJlBPQ0vUMoLnheoYLAXUorYekGLS330swHi58qQ=; b=mH/geOXEGnYqsmuGnOt3DOBMrwDtt4Bicy9ODTCJYTPGget1ux76yWY+cglw4YGDq0geyUJllb1PXBBwyAtszg5uCKSqqt/fFBe8Lp4UVcPHBoBoqw1zqe1Vs3GmUEM5ETERE6Ix/dHQbZKQ+RpT5+D9IUhKsHzLAJmAnCEky1IcNRixK8IRUNKxeSpMY7O0iDATJqCG9PqylREOvD05+HNZG6iNe6rrPljVN0dizyRsW1b2t//kYUaVN19SV87nYuk3ZBKZg8b11w6AfNhCi0W0GFaZPMuRAiYZ9f0CPdf6k2h2x3PckYOpJVUmWjmTH3CmJre/ux1mXmvWCNL9ag==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=stewe.org; dmarc=pass action=none header.from=stewe.org; dkim=pass header.d=stewe.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=steweorg.onmicrosoft.com; s=selector2-steweorg-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iigwJlBPQ0vUMoLnheoYLAXUorYekGLS330swHi58qQ=; b=hhhs2HzcL4daxg4hnJiJN/NH4rQj3/AZKpJw9/7WwBCbR1+I2+gyaSrb1ky7Ljhs5QsXUa87YiejX+CyT6F/rZYLribNCjo7UW2jM9a6o7jr0CNkEVhz3JVwy86AL+Tqn4za9RFcvGKeVHibpHhfIeEQX9vY4NCt0++Gb1czMpY=
Received: from PH0PR17MB4908.namprd17.prod.outlook.com (2603:10b6:510:d6::23) by DS0PR17MB6054.namprd17.prod.outlook.com (2603:10b6:8:cd::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6588.24; Thu, 13 Jul 2023 08:44:28 +0000
Received: from PH0PR17MB4908.namprd17.prod.outlook.com ([fe80::1e89:42c9:48a4:74d1]) by PH0PR17MB4908.namprd17.prod.outlook.com ([fe80::1e89:42c9:48a4:74d1%6]) with mapi id 15.20.6565.028; Thu, 13 Jul 2023 08:44:28 +0000
From: Stephan Wenger <stewe@stewe.org>
To: Robert Moskowitz <rgm@labs.htt-consult.com>, Alexandre Petrescu <alexandre.petrescu@gmail.com>, Stu Card <stu.card@axenterprize.com>
CC: "tm-rid@ietf.org" <tm-rid@ietf.org>
Thread-Topic: [Drip] ADSB
Thread-Index: AQHZtK4G+jaQ6m6eqE2Gq/oipVzt8K+2Bn4AgAAeTACAAAQrgIAADB0AgAADl4CAAATnAIAABQKAgAAFtACAAAN4gIABA+az
Date: Thu, 13 Jul 2023 08:44:28 +0000
Message-ID: <PH0PR17MB4908EAFD40B7B21A2A1480F1AE37A@PH0PR17MB4908.namprd17.prod.outlook.com>
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> <ee960fb3-e97d-85bd-8910-8b930bb9d760@gmail.com> <c7620042-f844-d9a4-c0fd-8dbaba1ec732@labs.htt-consult.com> <5cffd08e-9b79-31ca-16a7-49d3983aa487@gmail.com> <5cce0647-5db4-5061-bb00-e22cb9f6cf96@labs.htt-consult.com>
In-Reply-To: <5cce0647-5db4-5061-bb00-e22cb9f6cf96@labs.htt-consult.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=stewe.org;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH0PR17MB4908:EE_|DS0PR17MB6054:EE_
x-ms-office365-filtering-correlation-id: 2d843527-379f-4a3a-f93b-08db837d5e5b
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: xQ6teNGYw8JBUeF59IVgc6U5ywxjoQe9GnTpkIiIuWN9z80SgShYQsQ4ghLunAr6x6zdUpyWMpmMmRyxYxBIarQ/9aYKxb/3IJW8S2lUMHZkYPO+vSSZIbxGhqsV6RxSXubQ6iNGEKFTc8RKyr1jOmMFE0wMEHIt8DudeVqWppoLW4ofxRF0/L8S8two3XuJfyEZfpitr+YNs5Cp9u8HFLL6fy/GJi5JEcJ1GIeS3pqdSznjw4CrjDxP4wc5w/P9rSfKCE51ywvcfv9STyyyaU4ZGppPqqLYooOZLLVafRbBlR+94GpFOAvIx9H7l+SIyCSr911jk2gB7ogVyKA3AI/BlGDzvt2yUYwLg4Uc2ouDm45j01M4+1IVqkPsY0ydfOrXxIJw+Ha1BT/O5zsdMtLMk9UMCQdgmYv+z4Dktl8T5kSmIW2oQiTL/p2h8kWLHXu8SFp6SVNsJU2dN+WBVnfkzkQzfBdhqcmI9qgbaVxTE1O15odgm0IsN3bXC6azSzpwfVFwds2/XuJ12CxWgIHrj49yJ9z99YNFZKTqqTBBxZn9Pwek5xZCfj+OA950Qz+YMO7wOrZtB6xGtpio64s7t5V8FNG0xVfmQpgSNXE=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR17MB4908.namprd17.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(346002)(396003)(39830400003)(376002)(366004)(136003)(451199021)(186003)(41300700001)(45080400002)(316002)(110136005)(66556008)(66946007)(91956017)(76116006)(4326008)(66446008)(64756008)(7696005)(66476007)(71200400001)(966005)(9686003)(478600001)(9326002)(8676002)(8936002)(53546011)(6506007)(86362001)(166002)(52536014)(26005)(55016003)(5660300002)(33656002)(40140700001)(83380400001)(38070700005)(122000001)(2906002)(66574015)(30864003)(38100700002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: a7hYJipymtYiTYp53h0jde+nkR+v9psA5paBGCVu5kjeOMPhonNfxiUKWORZKYeEQN0R+a5t73wCy9BHqoslEIYS3tDK9/MMO+RM7t+5ypVBuviBXIP/oT509MJYXI2eTDPiaSmvxqGPwOp2t0UR1UrL6J+Xi6Du0or7oqqO+Ea76W8X18oo8aK6WybpyI02OzYPCVJXcF9arnoIF0H0vABpIlfI6zzEWNjVyZJaKArFmjJLZQifa7T/Yyk8y6E4PISRvtCBFMgb3OBuHS1eNTkJskcMVuqWJfiSW9umWK9sxgkXb/z1mmJfpDNi9pH4PilyDAwV3Gah5+f9F9c11Js9KZ895Au0SdPLCHxRt2MGMykqL3c3yp3CRyI/1t+boZmPy/9Fz1v/iKDdzz9hjPlzAOKtiIDif6WgSuCL1GnuK8EMs5qW8gXnOOHALzwKlLoBdWHJeX7ztAxA75nyfurwoXA8z+LjiJZAg4vr85pKGWUspoulNbmUrOypoCjcoEvVwrk5yb4EnMJefMz0xwzwFYZC3uPHb1IE0HEaZkA7KN9MnRU2DEg/KYmQ5zyln2TkAOCZZdvvxbTMlZh8vYOIaSY1TG5/f8uj+B6IcjOfEfGv5dSOTAPFbA7qg8fmsGgTrp2zSa5RrQR4dakhoRQ8SV/C5v1ZhTzOXSIreLfEk3w2SuWqZIwG/zSs2ajNRU4AIanSzqervNEDGhg/1KMTgDSF8jLbh+WwNrsEJCUU73j3zxDMrU9jhKqXCVAHoBlWlYFyacOeXHkvdiyVYgtRzPmAIoCDVPEwDXwFrBTEKOpH+9YFKr/uq3IRUDJqcJHxo8N3p2oH2XO/MYCMDVnP1ubmKqTEVc4Bd2jEYr02AYxQKJ15oM1E6xI6ngJmapTwDhBgWMlDFz2rNXcMbq/NjF+UwxwnaQoHA1uih0Knd/TyIV9TSNselrjt10CKG5lBRTJC2XCAUdDGrd6i7Ox/qcI9uIKNaB1wtEkeCSMm6zH+1uyt1JpdGUCVSkK6X4nQxX910MgsVDVoh9MtgBtbrLTplvrrnU3G39oTTCNa45uwTLoGNPyb8ldlFaNwAl7g+s0sDR3kqVBHXckAobBFH9UIpUW/w4H/sKJ1uc+pleW2s8tH/Twdmet7OzXF1mCNPD0pZGcxveuwrHBPEzrauxsAf2xJ04apUQjGGBqUhOFTNGlQpChjV7RoAEgsylTF6n8nb2qionS0bQb7U7Lxku0AtA5TzvBrDnm5+cgTW/qGfQ7X5swP5HDj+Di3ak/3W/843GngIUyQXcN9eOaybed+gFiTs5ciFeIH4+E4ja+xkVXD53ocgLt5dpWciYdXmMn+i4y/UXocUT76FOeWnU8z3pHEBnFm5rR+bnpMCm1kDD340S7lg9I5VPvQTPcqGnL8Hg6y+e+4KHdPreFziKiMxRg+E3uZyVYDDRE+h1g+GWpq/JnP0y2rtBRgNeL07bjqJ0WBw6z6sZoQqYX5UmMYUS9T8ZP/snhEs4GWeK074sukYq+Xb8S87z7mXngqsH70DVcJfnF4Js5ST8fSagaiUrGZrkOOE8Tla+tJbb1s9j6qs+Bnmr4874XM
Content-Type: multipart/alternative; boundary="_000_PH0PR17MB4908EAFD40B7B21A2A1480F1AE37APH0PR17MB4908namp_"
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR17MB4908.namprd17.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2d843527-379f-4a3a-f93b-08db837d5e5b
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2023 08:44:28.0197 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: T5QSPm2N95/X3cdZdqn6i1gzB+HV/iKxu1NrhcBdxsTKw8z7L78IjRl2UwFDptrd
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR17MB6054
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/biYkeb-dhpZ5mmsB0yaFCGOAxq8>
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: Thu, 13 Jul 2023 08:44:38 -0000

Hi,

Late to this party, but hopefully still with a bit of useful info about those ground-based and non-crewed-aircraft ADS-B transceivers.

ADSB-out is available and in use for airport ground vehicles in some countries, and on some selected airports in those countries, though AFAIK not in the US.  ADS-B ground transceivers can be bought commercially from the usual suspects (like here:   https://www.becker-avionics.com/portfolio/bav6215-ads-b-unit-ground-vehicles/).  In countries that allow ground-based ADS-B, the assignment of the 24 bit ICAO code is AFAIK strictly regulated and available only to essential airport vehicles (follow-me trucks, runway inspection, emergency vehicles) at selected major airports.  Ground controllers as well as aircraft crew can use the ADS-B for ground traffic management and avoidance.  In this context, ground-based ADS-B works because in those countries, the ADS-B fixed antennas are located on the airport (typically on the tower), and hence there is a line-of-sight between the antenna on the vehicle and the antenna on the tower.

When you look at the Geneva or Zurich airports in Switzerland, you can see those vehicles pretty much any time of the day.

ADS-B out is also in use for those UAVs that resemble manned aircraft in size and capability, and sometimes are derived from small crewed aircraft.  Above a certain weight threshold (like: 600 lbs), in many countries, all aircraft, unmanned or manned, must be equipped with Mode S transponders at least when entering certain types of airspace, hence already have the 24 bit ICAO code assigned. Plus/minus regulatory hurdles, they could use ADS-B also, using that registration.  One example of those large UAVs which can frequently been seen is callsign G-TEKV, which is used to monitor illegal immigration by small boat to England. It made news a while ago because of an engine-out incident.  Check it on flightradar24 if you wish.

Note that mode S transponders or ADS-B transceivers are not practical for anything smaller than a (man-carrying) ultralight—they weigh in at multiple kg/lbs and send (when queried—multiple times a second in busy airspace) at high power like 250W.  They also need WAAS-capable GPS, which is a weight factor also.

ADS-B is not a practical technology as a carrier for any signal other than those very limited signals defined by ICAO in the ADS-B context, for reasons that have been discussed on this list ad nauseam.

Stephan


From: Tm-rid <tm-rid-bounces@ietf.org> on behalf of Robert Moskowitz <rgm@labs.htt-consult.com>
Date: Wednesday, July 12, 2023 at 18:05
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, Stu Card <stu.card@axenterprize.com>
Cc: tm-rid@ietf.org <tm-rid@ietf.org>
Subject: Re: [Drip] ADSB

On 7/12/23 11:52, Alexandre Petrescu wrote:


Le 12/07/2023 à 17:31, Robert Moskowitz a écrit :



On 7/12/23 11:13, Alexandre Petrescu wrote:

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.

I am sure people do it.  How they get an aircraft number might be interesting.  Of course some transponders are preset for this from what I have heard.

Also I am away of code that takes "standard" Remote ID messages and feeds that into ADS-B systems.  So you see them in things like FlightAware, but they are NOT sending ADS-B.

Interesting.  If so then flightradar might say so somewhere on the
Internet.

See my draft:

https://datatracker.ietf.org/doc/draft-moskowitz-drip-crowd-sourced-rid/

For harvesting RemoteID messages to feed into UTM.  Feeding into ATC is probably not a good thing, IMHO.




of course you have to lie about the aircraft number,

For the aircraft type, registration and country of reg.: it says 'N/A'.
(for 'Not Available' I suppose - never knew what a dash had to do there,
as if it were 'Not/Available').

There is no 'aircraft number' in the page, but maybe you meant something
like that.

Also, even the legally carrying ADS-B aircraft sometimes dont provide
some of these ADS-B fields, or are some times badly read, or badly
interpreted.

But I am happy to see what is there to be seen.


going from the 20 character UA ID to the 24-bit aircraft number...

The 'ADS-B' drone I saw on flightradar said the 'ICAO 24-bit address'
was '511161' decimal I suppose.  Is there a means to check the validity
of this number?  Or to tilt to thinking it is a fake?

I do not know if there is a way for the general public to link the 24-bit address back to anything remotely interesting.   Just have not spent time in that direction.




The one effort I reviewed on this I asked this question, and they said the hashed the UA ID down to 24 bits...

Sure, we can do anything, put random or other crazy things in there -
but maybe it is not very good to play like that with these numbers.  But
I will not dispute that either.  I am just happy I could see it there.

If they hashed the UA ID to 24 bit for a 'standard' Remote ID of a drone
into ADS-B - would they do the same for a ground vehicle at the airport?
 Do ground vehicles at airport also likely carry 'standard' Remote IDs?
(obviously ignoring vehicles have other IDs like VINs...)

WE would like to see Trustworthy Remote ID (DRIP work) used beyond UAS!  I am working along these paths in ICAO.  Civil Aviation is pushing a PKI; FAA and EUROCONTROL are doing initial testing.  Aircraft and other moving things that participate could easily have DETs to use.  WIP.



Alex





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><https://aka.ms/AAb9ysg>

------------------------------------------------------------------------


*From:* Alexandre Petrescu <alexandre.petrescu@gmail.com><mailto:alexandre.petrescu@gmail.com>

*Sent:* Wednesday, July 12, 2023, 10:43 *To:* Stu Card <stu.card@axenterprize.com><mailto:stu.card@axenterprize.com>; Robert Moskowitz <rgm@labs.htt-consult.com><mailto:rgm@labs.htt-consult.com>; Carsten Bormann <cabo@tzi.org><mailto:cabo@tzi.org> *Cc:* tm-rid@ietf.org<mailto:tm-rid@ietf.org> <tm-rid@ietf.org><mailto: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><mailto:alexandre.petrescu@gmail.com> Sent: Wednesday, July 12, 2023 9:45 AM To: Robert Moskowitz <rgm@labs.htt-consult.com><mailto:rgm@labs.htt-consult.com>; Carsten Bormann <cabo@tzi.org><mailto:cabo@tzi.org> Cc: Stu Card <stu.card@axenterprize.com><mailto:stu.card@axenterprize.com>; tm-rid@ietf.org<mailto: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><mailto: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



-- Standard Robert Moskowitz Owner HTT Consulting C:248-219-2059 F:248-968-2824 E:rgm@labs.htt-consult.com<mailto:E:rgm@labs.htt-consult.com>

There's no limit to what can be accomplished if it doesn't matter
who gets the credit


--
Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      rgm@labs.htt-consult.com<mailto:rgm@labs.htt-consult.com>

There's no limit to what can be accomplished if it doesn't matter who gets the credit