Re: [Drip] ADSB

Robert Moskowitz <rgm@labs.htt-consult.com> Wed, 12 July 2023 15:06 UTC

Return-Path: <rgm@labs.htt-consult.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 02938C1516F3 for <tm-rid@ietfa.amsl.com>; Wed, 12 Jul 2023 08:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 B262F3ewjRsl for <tm-rid@ietfa.amsl.com>; Wed, 12 Jul 2023 08:06:10 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 AB7ACC14CF17 for <tm-rid@ietf.org>; Wed, 12 Jul 2023 08:06:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id E418062794; Fri, 1 Jan 2010 18:17:06 -0500 (EST)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id C7cfvZqrP4dh; Fri, 1 Jan 2010 18:16:48 -0500 (EST)
Received: from [192.168.160.29] (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id CAAC762620; Fri, 1 Jan 2010 18:16:47 -0500 (EST)
Content-Type: multipart/alternative; boundary="------------YLSvRUY0FQhWmqvmsMNBMPoZ"
Message-ID: <e8b938c6-f6f2-06d9-e9b1-ae0c8464e6ae@labs.htt-consult.com>
Date: Wed, 12 Jul 2023 11:05:47 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0
Content-Language: en-US
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, Stu Card <stu.card@axenterprize.com>, Carsten Bormann <cabo@tzi.org>
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>
From: Robert Moskowitz <rgm@labs.htt-consult.com>
In-Reply-To: <445a964b-75b5-cf36-633e-90ce70c0814b@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/FYIPqwe0aH0GTGmFV0u1gV5yo4M>
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:06:12 -0000


On 7/12/23 10:43, Alexandre Petrescu wrote:
>
>
> 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.

The RID rules are defined by the various Civil Aviation Authorities.  In 
the WG, we are working within those constraints to make them safer to use.


>
> 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'.

They assume a lot.  FAA rules on RID do not say this.  And we get into 
fun with barometric altitude or which model for earth shape???

>
> This kind of text could be of enormous help to implementers: they simply
> would need to call less functions(), because less need of conversions.


You would not believe (or maybe you would) the debates we had in ASTM 
over accurately reporting altitude with consumer grade electronics.  
Basically it is impossible.  So you go with "on average we are right and 
not reporting we are below ground level." :)

>
> 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.

Lots to read before you can play.  I think it is intentional to keep out 
those that are not committed to play with all the other participants.

>
> Also, about RID rules: they should say that when ASTM wants to send 
> position and heading they should send the NMEA statements, without 
> conversion.

ASTM F3411 is rather exact in such.  But in a "Declaration Of 
Compliance" it may be hard to show you meet the required accuracy. So 
just show test results that are accurate and not those tests where you 
were reporting flying below the ground.

>
> 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.

And why I don't expect autonomous flight to work on the large scale for 
quite some time.

>
>>
>> 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
>>>
>

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

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