Re: [Drip] ADSB - draft-moskowitz-drip-crowd-sourced-rid/

Robert Moskowitz <rgm@labs.htt-consult.com> Tue, 18 July 2023 14:34 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 EE503C151086 for <tm-rid@ietfa.amsl.com>; Tue, 18 Jul 2023 07:34:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 QrwSz7sUgwDP for <tm-rid@ietfa.amsl.com>; Tue, 18 Jul 2023 07:34:47 -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 B35F8C14CE47 for <tm-rid@ietf.org>; Tue, 18 Jul 2023 07:34:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 0E1E962775; Tue, 18 Jul 2023 10:34:07 -0400 (EDT)
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 zfw-JUfqIV-q; Tue, 18 Jul 2023 10:33:37 -0400 (EDT)
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 3F75B6275B; Tue, 18 Jul 2023 10:33:34 -0400 (EDT)
Content-Type: multipart/alternative; boundary="------------z7Ir7bTrXnnGSOVzuGJFZ2dl"
Message-ID: <084cdea3-6b48-a1e4-b1a2-e405af726264@labs.htt-consult.com>
Date: Tue, 18 Jul 2023 10:34:10 -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: Stephan Wenger <stewe@stewe.org>, Alexandre Petrescu <alexandre.petrescu@gmail.com>, Stu Card <stu.card@axenterprize.com>
Cc: "tm-rid@ietf.org" <tm-rid@ietf.org>
References: <6dfe8ea4-e803-5a70-c8eb-08eb3c1d4c4c@gmail.com> <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> <459b1c92-8f02-3359-1f78-8f610ea7cadc@gmail.com> <d7013a30-5d01-cf1b-674a-4a867e0af7d4@labs.htt-consult.com> <PH0PR17MB4908A49B6163BA0F51D22B3FAE38A@PH0PR17MB4908.namprd17.prod.outlook.com>
From: Robert Moskowitz <rgm@labs.htt-consult.com>
In-Reply-To: <PH0PR17MB4908A49B6163BA0F51D22B3FAE38A@PH0PR17MB4908.namprd17.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/kDePVPSoGnd_nr5Ih8vZTK87Mhs>
Subject: Re: [Drip] ADSB - draft-moskowitz-drip-crowd-sourced-rid/
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: Tue, 18 Jul 2023 14:34:53 -0000

For the most part I agree.

But when you are dealing with an aviation university like ERAU that HAS 
to teach its students about ADS-B, things like this happen and for them 
to then get some broader experience like writing up their project as a 
draft so others may consider it, why not?

But I am not going to spend time on it.  Well not much; there is 
discussion in a number of areas of how to get UA situational awareness 
into general/civil aviation without a big forklift.

see:

https://assureuas.com/wp-content/uploads/2021/06/First-Annual-Report-Final-v1.1-11-14-2022-WEBSITE.pdf

for some if the issues and thoughts about ADS-B, but no mention (that I 
see) about FIS-B.

After seeing videos of UA encounters with Cessnas (and try and actually 
see the UA!) and looking at a Cessna console on a lab rack at ERAU, I 
got to thinking what would it take to add Remote ID reception directly 
into the Garmin systems and have them filter UA information on the 
screens.  I got the impression that the systems already have the radios, 
but maybe not the antennas needed (on the lab rack, all antennas removed 
so the FAA does not ask what that Cessna is doing inside a building!).  
No need here for ADS-B or big forklifts.

On 7/18/23 10:16, Stephan Wenger wrote:
> Standard
>
> Hi,
>
> I think this WG should stick to its charter.  I think, the ADS-B based 
> tracking or ADS-B-based crowd-sourcing is not relevant under this 
> charter, as ADS-B is not, by the regulatory authorities, considered 
> for UAS Remote Identification.
>
> With that said, and please excuse the word count which is again due to 
> providing background info.
>
> I assume the most recent messages in this thread talk about ADS-B-In 
> to Bluetooth.  ADS-B-In is the information that comes down from 
> satellite which flightradar24 and in-cockpit devices and apps use to 
> create a traffic map, traffic warnings, and for other purposes.  
> Receiving and decoding this data is unregulated, relatively easy both 
> electronically and protocol-wise, and hence cheaply available.  You 
> can buy fully integrated devices such as this here 
> https://foreflight.com/products/portable-ads-b-receivers/ for a few 
> hundred dollars, which talk to the common aviation apps using 
> ASCII-based protocols that can easily be found on the web.  Many 
> pilots flying with older avionic stacks have those and an iPad, and 
> use them for situational awareness. That includes older airliners.  Or 
> you buy a software-defined radio stick for 30 bucks (like this: 
> https://www.nooelec.com/store/sdr/sdr-receivers/nesdr-mini-2-plus.html 
> ) and hack a few hundred lines of Python code.  For the latter, 
> there’s ample free documentation that five minutes with google will 
> make available to anyone interested, such as here: 
> https://habr.com/en/articles/447078/ There are also open source 
> projects.  Lots an lots of information is out there.
>
> What’s the use for an Internet Draft?
>
> As for crowd-sourcing to flightradar24, it IS crowd-sourced, today.  
> Please see here as an example: 
> https://www.flightradar24.com/apply-for-receiver. But, perhaps wisely, 
> they are currently not interested in signals other than ADS-B and MLAT 
> data as published by some ATCs (yellow planes) and space-based 
> transponder tracking (blue planes).  That’s a business decision on 
> their side, and a good one, IMO.
>
> As for ADS-B out (the aircraft-transmitting side of ADS-B): ADS-B-out 
> is strictly regulated, through the allocation of the 24 bit ICAO ID 
> and through radio frequency use.  Operating an unlicensed ADS-B 
> transmitter, in many countries, can get you into jail, and for good 
> reasons.  You don’t want to have 
> amateurs/idiots/youtube-submission-hunters send false ADS-B data 
> trying to show their cars or bicycles or something on flightradar24.  
> You definitely don’t want to have a ghost plane showing up on an 
> approach path and force an airliner you sit in to fly a missed, just 
> so that someone gets a few “likes”.  Luckily, and as already mentioned 
> on this list more than once, ADS-B-out is line of sight, and the 
> transmitting power is quite high, hence building a working ADS-B out 
> transmitter is not that easy or cheap, and you would have to drive to 
> the vicinity of an ADS-B ground station to do harm.  Also, near 
> airports, ADS-B data is cross-checked against radar data (manually by 
> the controllers, or automatically using MLAT nowadays), so we as 
> members of the flying public don’t have to worry too much about 
> spoofing. All this is known and understood by people who need to know, 
> including ATC personnel, pilots, regulators, and such.  The wider 
> IETF/Internet community does IMO not need to know, though they can 
> puzzle it out relatively easily when they start reading freely 
> available information.
>
> Again, what’s the use for an Internet draft?
>
> Thanks,
>
> Stephan
>
> *From: *Tm-rid <tm-rid-bounces@ietf.org> on behalf of Robert Moskowitz 
> <rgm@labs.htt-consult.com>
> *Date: *Tuesday, July 18, 2023 at 14:11
> *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 - draft-moskowitz-drip-crowd-sourced-rid/
>
> Alexandre,
>
> There is no draft.  It was a student project at Embry-Riddle Aviation 
> University 2 years ago.  They saw it as the "easy" part of the assignment!
>
> I am working with a couple of the profs there (and elsewhere) to see 
> if I can get them to actually do an Internet Draft on it for this fall.
>
> On 7/18/23 04:57, Alexandre Petrescu wrote:
>
>     I read the abstract of draft-moskowitz-drip-crowd-sourced-rid.
>
>     Disclaimer: I will not personally going to work on this, for other
>     reasons.
>
>     But I wanted to ask: we discussed about people converting between
>     other formats, presumably bluetooth formats, into ADS-B to display
>     in flightradar.  That discussion assumed a simple 1-1 conversion. 
>     Is there a draft about that? (I am asking, but I am not going to
>     work on it either for various reasons, but the question is
>     inevitable).
>
>     Alex
>
>     Le 12/07/2023 à 18:04, Robert Moskowitz a écrit :
>
>         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 <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 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
>
>                 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
>
>         There's no limit to what can be accomplished if it doesn't
>         matter who gets the credit
>
>
>
>

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