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

[Alexandre Petrescu <[e-mail]>]

Let me reply to the inner message, as the reply from Bob contains it,
and I have not received it otherwise.

Le 18/07/2023 à 16:34, Robert Moskowitz a écrit :
> 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 t
> 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 can agree.  Garmin sysems, including garmin 'pilot' watches, might
take a great advantages from displaying situational awareness data about
planes.  This concept of a driver's watch vibrating when another vehicle
approaches was demonstrated in automated cars, so why not with planes.

> I got the impression that the systems already have the radios, but
> maybe not the antennas needed

A garmin watch certainly has bluetooth and ANT+ and probably WiFi and
LTE interfaces.  At that point what one might need is two alternative
things:
- an external convertor from ADS-B or Remote ID into ANT+ or into
   Bluetooth.
- or an Internet connection in the plane, to which the watch might query
   flightradar, via watch's WiFi interface.

> (on the lab rack, all antennas removed so the FAA does not ask what
> that Cessna is doing inside a building!).

Fun!

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

Frankly speaking, for my part, I do not know the distinction between
ADS-B-In and -Out, so I learn.

>> ADS-B-In is the information that comes down from satellite

I am not sure satellite communication is systematically involved in
ADS-B communication.  I am under the impression that ADS-B functions
without satellite, in the most cases.

I can understand ADS-B-Out coming out of large transponders of large
airplanes, but I do not see the opposition to ADS-B-In.

It does not seem to be as if ADS-B-In was smaller transponders in
lighter aircraft vs ADS-B-Out larger transpoders in larger heavier aircraft.

There must be something else in there.

>> which flightradar24 and in-cockpit devices and apps use to create a
>> traffic map,

I think flightradar works without satcom in most cases, even though I am
not 100% sure.

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

Yes, I agree with what is said in this paragraph.

>> 
>> What’s the use for an Internet Draft?

An I-D might want to simply document what is already in use out there.
If already one single light drones sends Remote ID on bluetooth to a PC
that converts it into ADS-B data and uploads it to flightradar - that is
a deployed system which deserves being documented.

If it is documented then it represents a huge help to users of many
kinds.  A particular kind of of user of flightradar (like me) will be
very happy to know what means an 'ICAO a24bit ddress' that flighradar
displays about a light drone.

In a sense it represents a satisfaction of a simple curiosity, but in
many other senses, some times, it might represent a much more important
help.  For example some non-aviator people heard on radio airwawes (a
frequency around 123MHz) voices that were very important.  That happened
because they knew on which frequency to tune, because it is documented.

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

Sure, there is need of business for things to work.

If there is business in converting bluetoothRemoteID-to-ADSB then so be
it I-D, otherwise no.

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

True.  It might also be that an I-D gets written about how this
conversion RemoteID-ADSB of a light drone happens, and nobody uses that 
I-D. At that point one will say retrospectively that there was no need 
of that I-D, I agree.

Alex

>> 
>> Thanks,
>> 
>> Stephan
>> 
>> *From: *Tm-rid <[e-mail]> on behalf of Robert
>> Moskowitz <[e-mail]> *Date: *Tuesday, July 18, 2023
>> at 14:11 *To: *Alexandre Petrescu <[e-mail]>,
>> Stu Card <[e-mail]> *Cc: *[e-mail]
>> <[e-mail]> *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 <[e-mail]>
>> <mailto:[e-mail]>
>> 
>> *Sent:* Wednesday, July 12, 2023, 10:43 *To:* Stu Card
>> <[e-mail]> <mailto:[e-mail]>;
>> Robert Moskowitz <[e-mail]> 
>> <mailto:[e-mail]>; Carsten Bormann <[e-mail]>
>> <mailto:[e-mail]> *Cc:* [e-mail] <[e-mail]> 
>> <mailto:[e-mail]> *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
>> <[e-mail]> 
>> <mailto:[e-mail]> Sent: Wednesday, July 12,
>> 2023 9:45 AM To: Robert Moskowitz <[e-mail]> 
>> <mailto:[e-mail]>; Carsten Bormann <[e-mail]> 
>> <mailto:[e-mail]> Cc: Stu Card <[e-mail]> 
>> <mailto:[e-mail]>; [e-mail] 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 
>> <[e-mail]> 
>> <mailto:[e-mail]> 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:[e-mail]
>> 
>> 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: [e-mail]
>> 
>> 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:[e-mail]
> 
> There's no limit to what can be accomplished if it doesn't matter who
>  gets the credit